Pourquoi une équipe à distance a besoin d’écrire
Au bureau, une grande partie du savoir circule sans support : on demande au voisin, on entend une conversation, on regarde un collègue faire. À distance, ce savoir ne circule plus que s’il est écrit. Faute de documentation, les mêmes questions reviennent dans la messagerie, les réunions se multiplient pour transmettre des informations qui tiendraient sur une page, et l’équipe dépend de quelques personnes qui « savent ». Que l’une d’elles parte, tombe malade ou prenne trois semaines de congé, et c’est toute l’activité qui ralentit.
Les entreprises entièrement à distance en ont fait un principe. GitLab, dont tous les salariés travaillent à distance, publie son manuel interne en accès libre et défend une approche dite « handbook first », qui fait du manuel écrit le point de départ de la communication interne. Sans aller jusque-là, toute équipe hybride gagne à adopter un réflexe simple : quand une question est posée deux fois, la réponse mérite une page.
La documentation est aussi la condition de la communication asynchrone, décrite dans le chapitre sur la communication d’équipe à distance : on ne peut laisser chacun travailler à son rythme que si l’information de référence est accessible sans avoir à la demander. Avec la messagerie et la visioconférence, la base de connaissances forme le socle de la digital workplace d’une équipe.
Ce qu’il faut documenter en priorité
Vouloir tout documenter d’un coup est le meilleur moyen d’abandonner au bout de trois semaines. Commencez par ce qui coûte le plus cher quand l’information manque.
| Priorité | Contenu | Signal qui justifie de l’écrire |
|---|---|---|
| 1 | Fonctionnement de l’équipe : rôles, contacts, rituels, règles de communication | Les nouveaux arrivants posent toujours les mêmes questions |
| 2 | Procédures récurrentes : facturation, traitement d’une réclamation, clôture mensuelle | Une seule personne sait faire, ou les mêmes erreurs reviennent |
| 3 | Décisions et leurs raisons | On rediscute de sujets déjà tranchés |
| 4 | Outils et accès : où trouver quoi, à qui demander un accès | Des demandes d’accès bloquent le travail |
| 5 | Questions fréquentes de clients ou d’autres services | La même réponse est rédigée plusieurs fois par semaine |
| 6 | Savoir-faire rare : cas particuliers, historique d’un client, paramétrages | Un départ ou une absence longue se profile |
Les priorités 1 et 4 forment l’ossature du parcours d’arrivée. Une documentation à jour allège l’onboarding à distance : le nouvel arrivant peut chercher seul avant de demander, et son tuteur consacre son temps aux vraies questions.
Lancer la base en quatre semaines
- Semaine 1 : choisir l’espace, poser l’arborescence et les modèles de pages, nommer un référent.
- Semaine 2 : demander à chacun les cinq questions qu’on lui pose le plus souvent, puis rédiger les dix réponses les plus demandées.
- Semaine 3 : écrire les trois procédures que l’équipe ne peut pas se permettre de rater, avec la personne qui les maîtrise.
- Semaine 4 : ouvrir le registre des décisions, présenter la base en réunion d’équipe et adopter la règle « répondre par un lien ».
Structurer : arborescence, modèles de pages, responsables
Une base de connaissances se juge à une seule question : trouve-t-on la réponse en moins d’une minute ? Trois choix y contribuent.
Une arborescence courte et stable
Limitez-vous à deux ou trois niveaux et à des rubriques que tout le monde comprend : « Équipe », « Procédures », « Clients » ou « Projets », « Décisions », « Outils et accès ». Évitez de calquer l’arborescence sur l’organigramme, qui change plus souvent que le travail. L’outil importe moins que la discipline : un wiki intégré à la suite bureautique, un outil de documentation dédié ou un espace de fichiers bien rangé conviennent, à condition que toute l’équipe utilise le même. Le chapitre sur le choix des outils collaboratifs aide à trancher.
Des modèles de pages
Un modèle réduit l’effort d’écriture et rend les pages comparables. Le cadre Diátaxis, conçu par Daniele Procida pour la documentation technique, distingue quatre besoins qu’il vaut mieux ne pas mélanger dans une même page : apprendre (tutoriel), accomplir une tâche précise (guide pratique), vérifier une information (référence) et comprendre (explication). Transposé à une équipe, cela donne par exemple quatre modèles :
- Procédure : objectif, prérequis, étapes numérotées, points de vigilance, responsable, date de dernière vérification.
- Fiche de référence : contacts, paramètres, tarifs, liste des accès, sans commentaire superflu.
- Page d’explication : pourquoi l’équipe fonctionne ainsi, historique, options écartées.
- Parcours d’apprentissage : les premières semaines d’un nouvel arrivant, étape par étape.
À titre d’illustration, une procédure remplie selon ce modèle tient en quelques lignes :
Traiter une demande d’avoir client. Objectif : émettre un avoir conforme sous cinq jours ouvrés. Prérequis : accès au logiciel de facturation, accord écrit du responsable de compte au-delà d’un montant fixé par l’équipe.
Étapes : 1. Vérifier la facture d’origine et le motif de la demande. 2. Obtenir l’accord requis et l’archiver dans le dossier client. 3. Créer l’avoir dans le logiciel en le rattachant à la facture. 4. Envoyer l’avoir au client avec le modèle de courriel prévu. 5. Clore la tâche dans l’outil de suivi.
Vigilance : ne jamais modifier une facture déjà émise. Responsable : [nom]. Dernière vérification : [date].
Un responsable par page
Chaque page porte le nom de son responsable et la date de sa dernière vérification. Le responsable n’écrit pas forcément tout, mais il répond de l’exactitude. Une page sans responsable vieillit sans que personne ne s’en aperçoive.
Le registre des décisions
Les équipes distribuées perdent souvent moins de temps à décider qu’à redécider : faute de trace, une question tranchée en réunion revient trois mois plus tard, avec d’autres participants. Le registre des décisions règle ce problème. Il s’inspire des « Architecture Decision Records » décrits en 2011 par Michael Nygard pour les équipes de développement logiciel : un document court par décision importante, numéroté, avec un statut.
Chaque entrée comprend :
- Un numéro et un titre : « D-014 : facturation mensuelle des clients récurrents ».
- Le contexte : le problème, les contraintes, les options envisagées.
- La décision, formulée en une ou deux phrases, avec sa date et les personnes qui l’ont prise.
- Le statut : proposée, adoptée, remplacée (avec le numéro de la décision qui la remplace).
- Les conséquences : ce qui change, pour qui, à partir de quand.
Dans la logique de Nygard, les numéros ne sont jamais réutilisés et une décision dépassée n’est pas effacée : une nouvelle décision la remplace, et l’ancienne reste consultable avec la mention de ce remplacement. Le registre devient ainsi la mémoire de l’équipe, précieuse pour les nouveaux arrivants comme pour expliquer un choix à la direction. Règle pratique : une décision prise en réunion n’existe que lorsqu’elle figure dans le registre, idéalement dans les 48 heures.
Faire vivre la documentation : revues et règles de mise à jour
Une documentation fausse est pire qu’une absence de documentation : elle détruit la confiance, et l’équipe revient aux questions orales. Quatre règles la maintiennent en vie.
- Répondre par un lien. Quand une question a sa réponse dans la base, on répond avec le lien. Quand elle ne l’a pas, on répond, puis on crée ou complète la page. C’est la règle qui fait le plus pour l’usage.
- Mettre à jour au moment du changement. Une procédure modifiée est mise à jour avant d’être annoncée, et l’annonce renvoie vers la page.
- Revoir à date fixe. Une revue trimestrielle de trente minutes : chaque responsable confirme ses pages, archive les pages obsolètes, signale les manques. Les pages non vérifiées depuis un an sont signalées comme telles.
- Garder l’écriture légère. Une page courte et juste vaut mieux qu’un document parfait jamais terminé. Acceptez les brouillons, à condition qu’ils soient marqués comme tels.
La charte de communication d’équipe est le bon endroit pour inscrire ces règles, en particulier la distinction entre la messagerie, où l’on échange, et l’espace documentaire, où l’on conserve. Le manager donne l’exemple : s’il pose ses questions en message privé plutôt que de chercher dans la base, l’équipe fera de même.
Documentation et IA : rechercher et résumer sans perdre la source
Les assistants d’IA générative intégrés aux suites bureautiques et aux outils de documentation savent désormais chercher dans une base de connaissances et en résumer le contenu en réponse à une question. Bien utilisés, ils rendent la documentation plus accessible ; mal utilisés, ils en amplifient les défauts.
- La réponse ne vaut que ce que vaut la base. Un assistant qui puise dans des pages obsolètes produit des réponses obsolètes, formulées avec assurance. La revue des pages devient plus importante, pas moins.
- Toujours remonter à la source. Privilégiez les réponses qui citent les pages utilisées, et ouvrez la page avant d’agir sur une procédure, un chiffre ou une règle. Les modèles de langage peuvent produire des affirmations fausses mais plausibles.
- Respecter les droits d’accès. Avant de brancher un assistant sur l’espace documentaire, vérifiez qu’il ne montre à personne des documents que cette personne ne pourrait pas ouvrir directement : dossiers RH, données de clients, informations financières.
- Ne pas confier la base à un outil grand public. Copier des procédures internes ou des données de clients dans un assistant non validé par l’entreprise revient à les sortir de son contrôle.
- Utiliser l’IA pour écrire, pas pour valider. Elle aide à transformer des notes de réunion en procédure ou à repérer des pages redondantes ; le responsable de la page relit et valide le résultat.
Former l’équipe à ces réflexes de vérification fait partie du travail du manager. Les règles générales d’usage, notamment sur les données que l’on peut confier à un assistant, sont détaillées dans notre article sur l’IA générative en équipe.