Une rédaction technique que l'on peut vraiment suivre
Gjethe rédige de la documentation technique pour des logiciels, des produits et des processus internes : guides utilisateurs, articles de centre d'aide, références d'API et guides pour développeurs, documentation de prise en main, notes de version, procédures opérationnelles standard et bases de connaissances. Nos rédacteurs travaillent aux côtés des développeurs, testent ce qu'ils documentent et publient dans des outils comme GitBook, Docusaurus, Mintlify, Notion, Confluence ou votre service d'assistance, en anglais, en albanais ou en allemand.
- Première consultation gratuite
- Devis écrit pour votre projet
- Paiements échelonnés par étapes, avec souplesse
En un coup d'œil
- Types
- Guides utilisateurs, documentation d'API, centres d'aide, procédures opérationnelles standard
- Platforms
- GitBook, Docusaurus, Mintlify, Notion, Confluence
- Formats
- Markdown, MDX, OpenAPI, HTML
- Langues
- Anglais, albanais, allemand
Definition
Qu'est-ce que la rédaction technique?
La rédaction technique est l'art d'expliquer comment quelque chose fonctionne ou comment faire quelque chose, clairement et avec exactitude, pour un lecteur précis comme un client, un développeur ou un salarié.
La documentation fait partie du produit. Lorsqu'elle manque ou est erronée, les clients ouvrent des tickets de support, les développeurs renoncent à votre API et les nouveaux salariés posent les mêmes questions chaque semaine. Une bonne documentation est écrite pour un lecteur à la fois, testée par rapport au vrai produit et tenue à jour à mesure que le produit évolue.
À qui s'adresse-t-elle ?
Entreprises SaaS
Centres d'aide et guides de prise en main qui réduisent les tickets de support et accélèrent l'adoption.
Produits d'API et pour développeurs
Références et guides qui permettent aux développeurs d'intégrer sans vous écrire.
Entreprises du matériel et de l'industrie
Manuels, guides de mise en place et procédures de maintenance que l'on peut suivre en toute sécurité.
Équipes en croissance
Procédures internes et documents de prise en main qui préservent la façon dont le travail se fait.
Ce qui est inclus, et ce que vous conservez
Ce qui est inclus
- Audit de la documentation et analyse des lacunes
- Architecture de l'information et navigation
- Guides utilisateurs et articles pratiques
- Articles de centre d'aide
- Référence d'API à partir de votre OpenAPI ou de votre code
- Guides de démarrage rapide et tutoriels pour développeurs
- Notes de version et journaux des modifications
- Procédures opérationnelles standard
- Captures d'écran, images annotées et schémas simples
- Guide de style et modèles pour la future documentation
Ce que vous recevez
Remis en fin de mission. À vous pour toujours.
- Documentation publiée dans votre plateforme
- Fichiers sources en Markdown ou MDX dans votre dépôt
- Un guide de style de la documentation
- Modèles pour de nouveaux articles
- Une liste de contrôle de maintenance liée à votre processus de publication
De quelle documentation avez-vous besoin ?
| Lecteur | Ce dont ils ont besoin | Format typique |
|---|---|---|
| Nouveau client | Se mettre en route et obtenir un premier résultat | Guide de démarrage |
| Client existant | Accomplir une tâche précise | Articles d'aide par tâche |
| Développeur | Intégrer rapidement et gérer les erreurs | Référence d'API et démarrage rapide |
| Administrator | Configurer, sécuriser et gérer | Guide d'administration |
| Employé | Accomplir un processus toujours de la même façon | Procédure opérationnelle standard |
Nous testons ce que nous documentons
Le moyen le plus rapide de trouver les lacunes d'une documentation est de la suivre. Nos rédacteurs parcourent chaque guide dans un compte de test ou un bac à sable, notent où le produit et les instructions diffèrent et soulèvent des questions auprès de vos développeurs avant la publication.
Pour les API, nous appelons les points d'accès, vérifions les exemples de requêtes et de réponses et nous assurons que les messages d'erreur sont expliqués. Des exemples qui ne fonctionnent pas sont l'une des principales raisons pour lesquelles les développeurs abandonnent une intégration.
La documentation comme code
Pour les produits destinés aux développeurs, la documentation vit souvent mieux à côté du code : Markdown ou MDX dans votre dépôt, relu dans les pull requests et publié automatiquement avec des outils comme Docusaurus, Mintlify ou GitBook. Cela garde la documentation versionnée avec le produit et fait des mises à jour une partie de chaque publication.
Pour les centres d'aide destinés aux clients, la plateforme de service d'assistance elle-même est généralement le bon support, pour que les articles puissent être reliés depuis les réponses du support et recherchés depuis le produit.
Une documentation que les assistants IA peuvent lire
Les clients demandent de plus en plus à ChatGPT, à Claude ou à votre propre bot de support comment utiliser votre produit. Des intertitres clairs, une tâche par article, des prérequis explicites et des exemples exacts rendent la documentation plus facile à citer correctement pour ces outils. Nous pouvons aussi publier un index llms.txt de votre documentation pour que les outils d'IA trouvent les bonnes pages.
Signes que votre documentation demande du travail
- Le support répond chaque semaine aux mêmes questions pratiques
- Les captures d'écran montrent une ancienne version du produit
- Les développeurs demandent des exemples lors des appels commerciaux
- Les nouveaux salariés apprennent les processus en demandant autour d'eux
- Personne n'est responsable de la mise à jour de la documentation après une publication
- La recherche dans votre centre d'aide trouve rarement la réponse
Des notes de version que les clients lisent
Les notes de version sont souvent écrites pour l'équipe qui a construit la fonctionnalité. Les clients veulent savoir ce qui a changé pour eux, s'ils doivent faire quelque chose et où en apprendre davantage. Nous rédigeons des notes de version qui s'ouvrent sur le bénéfice, expliquent toute action requise et renvoient vers l'article d'aide mis à jour.
Pour les produits destinés aux développeurs, nous tenons à côté un journal des modifications précis : versions, changements incompatibles, dépréciations et étapes de migration, pour que les intégrateurs puissent mettre à niveau sans surprise.
Comment fonctionne la rédaction technique, étape par étape
Chaque étape produit un résultat clair que vous pouvez relire. Le calendrier est convenu dans votre devis.
- 1
Audit
Nous examinons la documentation existante, les tickets de support et les statistiques pour trouver les lacunes.
- 2
Structure
Lecteurs, sujets et navigation convenus avant la rédaction.
- 3
Rédiger et tester
Brouillons rédigés en suivant chaque étape dans le produit.
- 4
Révision
Relecture technique par votre équipe, puis relecture pour la clarté.
- 5
Publier
Publié dans votre plateforme avec des modèles pour de futurs articles.
- 6
Maintenir
Mises à jour facultatives liées à votre processus de publication.
Les outils, et ce qui détermine votre devis
Le prix dépend de votre projet et est convenu dans votre devis. Voici ce qui le fait varier.
| Facteur | Pourquoi c'est important |
|---|---|
| Nombre d'articles ou de pages | Plus de sujets signifient plus de recherche, de rédaction et de relecture. |
| Profondeur technique | La documentation d'API et pour développeurs demande plus de tests que les guides utilisateurs. |
| Accès aux experts | Des réponses rapides de votre équipe gardent le travail efficace. |
| Visuals | Les captures d'écran, les images annotées et les schémas ajoutent du temps de production. |
| Langues | Chaque langue supplémentaire demande une traduction et une relecture. |
| Mise en place de la plateforme | Mettre en place une nouvelle plateforme de documentation ajoute du travail initial. |
| Domaine | Tools |
|---|---|
| Plateformes de documentation | GitBook, Docusaurus, Mintlify, ReadMe, Confluence, Notion |
| Centres d'aide | Zendesk Guide, Intercom Articles, Help Scout Docs, HubSpot Knowledge Base |
| API | OpenAPI, Postman, Swagger UI, Redoc |
| Visuals | Snagit, Figma, Excalidraw, Mermaid |
Erreurs courantes à éviter
Ce qui tourne le plus souvent mal, et comment un bon projet l'évite.
Écrire pour tout le monde à la fois
Une page pour les débutants et les experts ne sert aucun des deux. Écrivez pour un lecteur par page.
Documenter des fonctionnalités plutôt que des tâches
Les gens arrivent avec quelque chose à faire. Organisez autour de ce qu'ils veulent accomplir.
Des exemples qui ne fonctionnent pas
Des extraits de code cassés détruisent la confiance plus vite qu'une documentation manquante.
Pas de responsable après le lancement
La documentation devient obsolète en quelques versions, sauf si sa mise à jour fait partie de la publication.
Questions fréquentes
Vos rédacteurs comprennent-ils les produits techniques ?
Oui. Nos rédacteurs travaillent chaque jour avec des développeurs, lisent du code et des API et testent ce qu'ils documentent dans le produit lui-même.
Pouvez-vous rédiger la documentation d'API à partir de notre fichier OpenAPI ?
Oui. Nous utilisons votre spécification OpenAPI comme source de la référence et ajoutons autour d'elle des guides, des exemples et des explications sur les erreurs.
Sur quelles plateformes publiez-vous ?
GitBook, Docusaurus, Mintlify, ReadMe, Confluence, Notion et bases de connaissances de services d'assistance, ou du simple Markdown dans votre dépôt.
Pouvez-vous documenter des processus internes ?
Oui. Nous rédigeons des procédures opérationnelles standard et des guides de prise en main en interrogeant les personnes qui font le travail et en testant les étapes.
Traduisez-vous la documentation ?
Nous rédigeons en anglais, en albanais et en allemand, et pouvons produire d'autres langues via des traducteurs professionnels.
Pouvez-vous tenir notre documentation à jour après chaque publication ?
Oui. Nous pouvons relire les notes de version et mettre à jour les pages concernées dans le cadre d'un accord continu.
Utilisez-vous l'IA pour rédiger la documentation ?
Nous pouvons utiliser l'IA pour des premiers plans ou des résumés, mais chaque page est écrite, testée et vérifiée par une personne par rapport au vrai produit.
Comment la rédaction technique est-elle chiffrée ?
Elle est chiffrée selon le nombre de pages, la profondeur technique, les visuels et les langues, après examen de ce qui existe.
Pouvez-vous travailler à partir d'enregistrements d'écran et d'appels avec nos développeurs ?
Oui. De courts enregistrements ou des appels avec les personnes qui ont construit une fonctionnalité sont souvent le moyen le plus rapide de démarrer, et nous les transformons en guides structurés et testés.
Rédigez-vous les textes dans le produit, comme les infobulles et les messages d'erreur ?
Oui. Les microtextes sont étroitement liés à la documentation, et garder la formulation cohérente entre le produit et la documentation aide les utilisateurs.
Pouvez-vous migrer notre documentation vers une nouvelle plateforme ?
Oui. Nous déplaçons et restructurons le contenu existant, corrigeons les liens cassés et mettons en place des redirections pour que les anciennes URL fonctionnent toujours.
Services associés
Rédaction de contenu
Textes de site, articles et descriptions rédigés par des humains.
Développement d'API sur mesure
API REST, GraphQL et WebSocket documentées.
Traduction et localisation
Un contenu adapté à chaque langue et à chaque marché.
Support client
Support par e-mail, chat et helpdesk pour vos clients.
Rédaction technique par secteur
Rendez votre produit plus facile à utiliser.
Dites-nous ce dont vous avez besoin. Vous recevez une évaluation honnête, un plan clair et un devis écrit. La première consultation est toujours gratuite.
- Et ensuite ?
- 1Vous nous dites ce dont vous avez besoin
- 2Nous nous efforçons de répondre sous 24 heures avec des questions
- 3Vous recevez un devis écrit pour votre projet