Wiki interne : outils, structure et le wiki qui naît de l'historique du canal (2026)

Un wiki interne est l'ensemble des pages qu'une organisation écrit pour elle-même et pour personne d'autre : comment un nouveau distributeur est configuré, où se trouve la grille tarifaire en vigueur, ce qui a été décidé sur les remises en juin, qui appeler quand le transporteur est en retard. Il est interne parce que le lecteur est un collègue, et c'est un wiki parce que tout membre peut écrire une page et que toute page peut renvoyer vers une autre. Une organisation de 10 à 200 personnes en possède un dès le jour où une deuxième personne pose la même question : le seul choix est de savoir si les pages existent, ou si la réponse vit dans la tête d'un collègue et dans une douzaine de fils de discussion.

La plupart des guides sur les wikis internes sont des listes de logiciels. Celui-ci commence plus tôt, parce que l'outil est la plus petite des décisions : un wiki qui fonctionne est une structure dans laquelle on s'oriente, un format de page qui reste fiable et un endroit que l'équipe ouvre déjà chaque jour. Le savoir-faire vient d'abord — la structure, un modèle de page à copier, un exemple concret tiré d'une clinique — puis la mécanique : où vit le wiki dans les outils que votre équipe utilise déjà, d'après leur propre documentation, et ce que chacun fait de la réunion où la règle a réellement été fixée. Car le test d'un wiki n'est pas le jour de son lancement. C'est le lundi où un nouveau collègue l'ouvre et trouve la page dans une langue qu'il lit.

Ce qu'est un wiki interne — et ce qu'il n'est pas

Quatre choses sont appelées « wiki », et la confusion entre elles explique pourquoi tant sont construits et si peu sont ouverts :

Le wiki est la première ligne, et c'est celle dont dépendent les trois autres. Une base de connaissances est un wiki dont la structure est imposée : une entrée par question et un responsable pour chacune ; la méthode pour en construire une en 30 jours se trouve dans ce guide, et celui-ci traite de la forme propre du wiki. L'intranet est ce que devient le wiki quand seules trois personnes ont le droit d'écrire. Le lecteur partagé est l'endroit où vivent les fichiers du wiki, et le rôle du wiki est de pointer vers la version en vigueur. Un wiki n'est pas non plus un document de processus ni une procédure opérationnelle standard : ceux-ci décrivent une tâche de bout en bout ; une page de wiki indique où les trouver et ce qui a changé depuis.

Ce qui rend un wiki interne, ce n'est pas un mot de passe. C'est que les pages sont écrites avec les mots de l'équipe — « la règle de Casablanca », « la tournée du mardi » — et qu'elles peuvent dire ce qu'une page externe ne dirait jamais : qui a décidé, pourquoi, et ce que cela a remplacé.

La structure : sept sections, une page par question

La différence entre un wiki que l'on ouvre et un wiki que l'on a cessé d'ouvrir tient rarement à l'outil. Elle tient à trois décisions prises, ou non, avant la première page.

Des sections par question, pas par service. Le collègue qui demande « comment facturer un distributeur en Suisse ? » ne sait pas si la réponse relève de la finance, des ventes ou de la logistique ; il connaît la question. Un wiki organisé par service l'envoie dans trois sections pour trouver une seule page. Organisez par les questions que les gens posent, avec leurs mots, et limitez le premier niveau à sept sections au plus. Au-delà de sept, la structure elle-même a besoin d'une recherche, et une recherche dans un wiki que personne n'a encore rempli ne renvoie rien. Premiers niveaux typiques pour une petite organisation : clients et commandes ; argent et facturation ; personnes et recrutement ; outils et accès ; règles et décisions ; qui appeler.

Une page par question, tenant sur un écran. Une page qui répond à une question est trouvée et lue ; une page qui explique toute une fonction est mise en favori et parcourue en diagonale. « Comment facturer la Suisse ? » est une page. « Finance » est une section. Si une page a besoin d'une table des matières, ce sont deux pages.

Un responsable et une date sur chaque page. Une page qui indique qui en est responsable et quand elle a été vérifiée pour la dernière fois est crue ; le même texte sans ces mentions est « probablement périmé ». Le travail du responsable est modeste — une fois par trimestre, répondre à « est-ce toujours juste ? » et changer la date — et c'est la seule chose qui maintient un wiki en vie au-delà de sa première année. Une page pour laquelle on ne peut nommer personne n'est pas une connaissance ; c'est une supposition, et elle sort du wiki.

Deux habitudes préservent la structure une fois en place. Toute réponse donnée dans le canal de l'équipe et demandée deux fois devient une page, écrite par celui qui a répondu, liée depuis la section à laquelle elle appartient. Et toute décision qui modifie une règle reçoit d'abord sa ligne dans le relevé de décision, puis la page qui énonce la règle renvoie vers lui — ainsi, six mois plus tard, la page peut dire non seulement quelle est la règle, mais pourquoi.

Comment créer un wiki interne en une semaine

Le plan suppose une personne qui pilote — le responsable d'équipe, ou celui à qui l'on pose le plus de questions — et le reste de l'équipe qui y consacre quelques minutes.

Jour 1 — choisir l'endroit selon l'endroit où l'équipe lit déjà. Pas selon un comparatif de logiciels. Le wiki vit là où les questions sont posées : le canal de l'équipe, la suite où se trouvent déjà les fichiers. Un wiki dans un cinquième outil avec son propre login est un wiki que personne n'ouvre un lundi matin. Le tableau plus bas indique ce que garde chaque endroit et où chacun s'arrête.

Jours 1 à 3 — collecter les questions, pas les réponses. Publiez un message dans le canal : « Répondez avec chaque question que vous avez posée à un collègue cette semaine, avec les mots que vous avez employés. » Au troisième jour, il y en a quarante à soixante ; un tiers sont des doublons. Comptez les répétitions : la question posée cinq fois est la page numéro un.

Jour 4 — trier en sept sections, nommer les responsables. Les groupes dans lesquels tombent les questions sont les sections. Nommez un responsable par section — la personne qui a répondu à la plupart de ses questions — et un responsable pour chacune des quinze premières pages. N'écrivez encore rien d'autre que la liste : section, question, responsable. Renvoyez-la à l'équipe avec une seule question : « que manque-t-il ? »

Jours 5 à 7 — les quinze premières pages, à partir de ce qui existe déjà. Chaque responsable écrit ses pages avec le modèle ci-dessous, en partant de la réponse dans le chat, du compte rendu de la réunion où la règle a été fixée, du fichier joint en mars. La règle de la première semaine est « court et vrai vaut mieux que long et complet » : une réponse de deux phrases avec un lien vers le fichier, datée et signée, est une page. Épinglez ensuite l'index des sections là où l'équipe lit, et le wiki existe.

Ce qui n'arrive pas pendant cette semaine : migrer le lecteur partagé, écrire une page pour chaque processus, choisir un nouvel outil. Le wiki pointe vers les fichiers là où ils sont et vers les procédures là où elles vivent.

Un modèle de page de wiki interne

Une page, une question, tenant sur un écran. Copiez-le comme une note et remplissez-le ; les lignes les plus souvent oubliées sont les trois dernières, et ce sont elles qui maintiennent la page exacte.

[Question, avec les mots que les gens emploient pour la poser]
Responsable : [nom] · Section : [l'une des sept] · Dernière relecture : [date] · Prochaine relecture : [date]
Réponse courte : [deux phrases — ce qu'il faut faire]
S'applique à : [équipe, bureau, type de client] · Ne s'applique pas à : [le cas que l'on confond avec celui-ci]
Comment : [étapes numérotées, chacune nommant le système, la personne ou le fichier concerné]
La règle derrière : [la décision qui l'a fixée, avec sa date et sa raison — lien vers le relevé de décision]
Exceptions : [les cas hors du chemin habituel, et qui décide pour chacun]
Où sont les fichiers : [lien vers le modèle, la grille tarifaire, le contrat en vigueur]
Pages liées : [la procédure, le processus, la version précédente de cette page]

Le modèle est du texte brut avec des libellés en gras, il se colle donc dans un fichier Word, un Google Doc, une page de wiki, un canvas Slack ou une note de chat sans remise en forme.

Un exemple concret : le wiki d'une clinique après une semaine

Une clinique de kinésithérapie à Barcelone, 24 personnes : un accueil de quatre personnes, quatorze thérapeutes, deux à la facturation, le reste en administration. La moitié des thérapeutes sont arrivés d'Argentine, de Colombie et d'Ukraine ces deux dernières années ; un tiers des patients sont des résidents britanniques et allemands qui réservent en anglais. Trois jours de collecte ont produit 52 questions ; après élimination des doublons, 37. La structure qui en est sortie, avec le nombre de pages par section au septième jour :

1. Patients et rendez-vous (5) — comment un premier rendez-vous est réservé ; que faire en cas d'absence ; comment un patient change de thérapeute
2. Facturation et assurances (4) — quels assureurs sont facturés directement ; comment un reçu pour un assureur étranger est émis ; quand une séance est remboursée
3. Protocoles de traitement (3) — où se trouvent les fiches de protocole ; qui valide un plan de traitement ; ce qui est consigné après chaque séance
4. Outils et accès (2) — qui donne l'accès au système de réservation ; où se trouvent les modèles de courrier aux patients
5. Règles et décisions (2) — la règle d'annulation à 24 heures ; le relevé de décision
6. Qui appeler (1) — les contacts des assureurs ; la ligne de service du matériel

Dix-sept pages. La question la plus fréquente — « comment émettre un reçu qu'un assureur allemand acceptera ? » — avait reçu une réponse à l'accueil neuf fois en un an, toujours de la même responsable de la facturation ; la page lui a pris quinze minutes, parce que la neuvième réponse était déjà écrite dans le canal et n'avait besoin que de la ligne du responsable et de la date.

Une page remplie, tirée de la section 2 :

Comment émettre un reçu qu'un assureur étranger acceptera ?
Responsable : Responsable de la facturation · Section : Facturation et assurances · Dernière relecture : 6 novembre 2026 · Prochaine relecture : 6 février 2027
Réponse courte : Utiliser le modèle « reçu assureur », dans la langue du patient, avec le code de diagnostic et le numéro d'autorisation d'exercer du thérapeute sur chaque ligne.
S'applique à : patients qui paient eux-mêmes et se font rembourser par un assureur à l'étranger · Ne s'applique pas à : assureurs que nous facturons directement, qui reçoivent le relevé mensuel.
Comment : 1. Ouvrir le patient dans le système de réservation. 2. Choisir le modèle de reçu assureur. 3. Ajouter le code de diagnostic issu du plan de traitement. 4. Vérifier que le numéro d'autorisation figure sur chaque ligne. 5. Envoyer en PDF et classer une copie dans le dossier du patient.
La règle derrière : Les numéros d'autorisation ont été ajoutés après les refus allemands d'avril 2026 (entrée du relevé de décision du 2026-04-22).
Exceptions : Un patient qui a besoin d'un reçu détaillé par séance s'adresse à la responsable de la facturation ; personne d'autre n'en émet.
Où sont les fichiers : Modèle de reçu assureur ; liste des codes de diagnostic ; dossiers des patients.
Pages liées : Quels assureurs sont facturés directement ; quand une séance est remboursée.

Où vit le wiki dans les outils que vous utilisez déjà

Une organisation de 10 à 200 personnes construit son wiki dans la suite qu'elle paie déjà, et chaque suite a un endroit pour la page, un endroit pour les fichiers et un chemin pour ce qu'une réunion laisse derrière elle. Chacune s'arrête à un point différent, et dans chacune la page est dans la langue où elle a été saisie. Uniquement le comportement documenté, d'après les pages des éditeurs eux-mêmes, avec le mois de vérification de chaque page :

Trois choses sont identiques dans les quatre. La page est un document ou un message dans la seule langue où elle a été saisie, et un membre qui lit une autre langue lit celle-là ou une copie que quelqu'un a faite. Les fichiers sont à un second endroit, trouvés par une seconde recherche. Et la réunion — où la règle a été débattue et fixée — n'atteint le wiki que lorsqu'une personne la retape ensuite : où Teams et Meet conservent une transcription et un résumé, le cas échéant, et comment les garder après l'appel, se trouve dans où Microsoft Teams et Google Meet stockent votre transcription, enregistrement et résumé ; les outils de prise de notes par IA que de nombreuses équipes ajoutent pour la même raison sont comparés dans alternatives à Otter.ai, et chacun écrit son résumé dans une seule langue.

La traduction que ces suites documentent appartient à l'appel ou à l'écran du lecteur, pas à la page : Microsoft documente les sous-titres traduits en direct dans les réunions Teams lorsque l'organisateur dispose d'une licence Teams Premium ou Microsoft 365 Copilot, Google documente les sous-titres traduits dans Meet sur les offres Workspace éligibles (les deux vérifiés en août 2026), et WhatsApp documente la traduction d'un message reçu sur le téléphone du lecteur (vérifié en août 2026) — ce que chacun couvre et où chacun s'arrête est détaillé dans traduction en direct dans Microsoft Teams, traduction en direct dans Google Meet et traduire dans WhatsApp. La page du reçu que le thérapeute ukrainophone ouvre le lundi est un objet distinct de ces sous-titres, et elle se lit dans la langue où elle a été saisie.

Le wiki qui naît de l'historique du canal

InterMIND est un espace de communication où le travail d'une équipe vit dans un canal ; le wiki a donc une place évidente : le canal de l'équipe qui l'utilise — l'accueil de la clinique, l'équipe export, le groupe de comptes de l'agence — et ce canal est aussi l'endroit où les questions sont posées et d'où partent les réunions. Les trois décisions évoquées plus haut s'y appliquent directement.

Les pages et leurs responsables sont des notes dans le canal. Une note est un message en texte enrichi avec des titres et des listes numérotées, modifiable ensuite depuis son propre menu, et chaque membre la lit dans sa propre langue, l'original n'étant qu'un basculement plus loin ; une fois épinglé, l'index des sections est la première chose qu'un nouveau collègue trouve. Avec l'historique de modifications activé, la formulation antérieure d'une règle modifiée apparaît au-dessus du texte actuel sous forme de différence au niveau du mot, avec son horodatage — la piste de relecture vers laquelle pointe la ligne « dernière relecture » du responsable. Les fichiers vers lesquels une page pointe — le modèle de reçu, la liste des codes de diagnostic, le contrat de l'assureur — sont téléversés dans le même canal et portent, sur toutes les offres, un résumé par IA dans la langue du lecteur, chaque point étant lié au paragraphe d'où il provient ; sur les offres payantes, le fichier lui-même s'ouvre traduit dans la langue du lecteur (30 langues pour les documents). Si l'exemplaire de référence reste dans un outil de documents, ses mises à jour arrivent dans le canal par e-mail : l'hôte du canal lui attribue une adresse propre, et un message envoyé à cette adresse apparaît comme un message ordinaire, avec l'expéditeur nommé et les pièces jointes conservées. Une équipe qui arrive de Slack emmène ses canaux avec elle : un export standard d'espace de travail Slack se restaure en un canal par canal Slack, avec les messages dans l'ordre et leurs horodatages d'origine, les messages épinglés et les réactions conservés, chaque message étant lu par chaque membre dans sa propre langue.

L'historique derrière chaque page est l'endroit où le canal fait le travail que le tableau ci-dessus laisse à une personne. La réunion où la règle est fixée part du canal ; pendant l'appel, le brouillon de la page s'affiche sur l'écran de chacun à côté des vignettes vidéo avec Share to conference — une note, ou un document Google Docs ou OneDrive lié dans le chat — et chaque participant le fait défiler indépendamment et le lit dans sa propre langue, pendant que la personne qui le partage le modifie en direct. À la fin de l'appel, le compte rendu est rédigé à partir de la réunion elle-même — un résumé, les points marqués comme convenus, ouverts ou contestés, les action items avec leurs responsables, chaque ligne conservant son horodatage — et les documents partagés pendant la session apportent leurs résumés à côté de ce qui a été dit. Il arrive par e-mail, sous forme de message dans le canal et sous forme de lien dans l'événement du calendrier, et chaque membre connecté le lit dans sa propre langue : la trace est traduite par lecteur, et non écrite une fois dans la langue que la salle a utilisée. Tout membre peut la modifier, chaque modification conserve son auteur et l'historique des révisions, et le canal garde le compte rendu de chaque session passée — la réunion qui a fixé la règle du numéro d'autorisation est donc à un clic de la page qui l'énonce. C'est cela, le wiki qui naît de l'historique du canal : la neuvième réponse à l'accueil, le compte rendu de l'appel où la règle a été débattue, le modèle joint en avril, le tout au même endroit, avec la page par-dessus. Mis en regard du tableau ci-dessus, la différence est un simple constat : les sous-titres que ces suites documentent traduisent l'appel pendant qu'il se déroule ; ici, la page, les réunions qui l'ont produite, ses fichiers et son historique forment une seule trace, lue par chaque membre dans sa propre langue.

Le canal des questions reçoit le même traitement dans l'autre sens. L'assistant personnel d'un membre — Claude, ChatGPT, Copilot ou Gemini, connecté via le connecteur MCP — recherche dans les comptes rendus, les transcriptions, les chats et le texte des fichiers partagés en une seule question, « comment émettons-nous un reçu qu'un assureur allemand acceptera ? », et renvoie les passages avec la réunion, la date et le fichier dont chacun provient ; cela fonctionne pour les organisations dont les fonctions d'IA sont activées, et la lecture via l'assistant est limitée aux réunions et aux canaux dont le membre fait partie. Le chat lui-même dispose d'une recherche, et le wiki peut être exporté en entier : sur toutes les offres, une sauvegarde depuis les paramètres exporte les canaux dans un ZIP avec leurs messages, transcriptions et fichiers — la question de la propriété réglée au niveau de l'organisation plutôt qu'à celui de la page.

Les personnes qui détiennent le savoir d'une équipe ne sont pas toujours des salariés. Le contact sinistres de l'assureur, le technicien du matériel, le comptable indépendant qui connaît la règle allemande des reçus : un membre externe du canal le rejoint par e-mail avec un compte gratuit et lit les pages et leur historique comme tout le monde ; une personne sans compte est invitée à une seule réunion — elle rejoint l'appel par lien, depuis un téléphone, sans frais, l'entend en direct dans sa propre langue, et n'obtient aucune trace ensuite. L'hôte fournit l'espace et, sur une offre payante, ne paie que les membres actifs au cours des 28 derniers jours — ceux qui ont rejoint une réunion, écrit dans un chat ou interrogé l'assistant ; les membres qui deviennent silencieux conservent leur accès sans frais, ce dont un wiki a besoin : la personne qui a écrit la page il y a deux ans peut toujours être dans le canal.

• Ouvrir un compte rendu complet — une vraie trace, produite par le même code que celui qui rédige les vôtres.
• Essayer la démo en ligne — sans inscription ; parlez, et entendez la salle traduite pour chaque auditeur.

Un wiki interne, en tant que savoir-faire, survit à tous les outils : quelqu'un doit toujours collecter les questions, limiter la structure à sept sections, mettre un nom et une date sur chaque page, et répondre dans le canal plutôt que par message direct. Ce qui n'a pas à survivre, c'est le second travail — retaper dans le wiki ce que la réunion a décidé, et tenir à la main une copie traduite de chaque page, une langue à la fois, pour les collègues qui lisent l'autre.

FAQ

Qu'est-ce qu'un wiki interne ?

Un wiki interne est un ensemble de pages qu'une organisation écrit pour ses propres membres — comment les choses se font, où sont les fichiers, ce qui a été décidé et pourquoi — réunies en un seul endroit, où tout membre peut écrire une page et où toute page peut renvoyer vers une autre. Il se distingue d'un wiki public par son lecteur, un collègue plutôt qu'un client, et d'un intranet par le fait que ce sont les personnes qui font le travail qui écrivent et mettent à jour les pages, et non une équipe centrale. Les pages qui sont ouvertes sont celles organisées selon les questions que les gens posent, avec un responsable et une date de relecture sur chacune.

Quelle est la différence entre un wiki interne et une base de connaissances ?

Un wiki est un ensemble de pages que chacun peut écrire dans n'importe quelle structure ; une base de connaissances est organisée selon les questions que les gens posent, avec une entrée par question et un responsable et une date de relecture nommés pour chacune. Un wiki devient une base de connaissances en y ajoutant la structure et les responsables ; sans eux, il se transforme en centaines de pages dans lesquelles personne ne s'oriente et que personne n'a vérifiées. Le logiciel est souvent le même, et la méthode pour passer de l'un à l'autre en 30 jours se trouve dans comment construire une base de connaissances.

Comment créer un wiki interne ?

Choisissez l'endroit selon l'endroit où l'équipe lit déjà, pas selon un comparatif de logiciels ; collectez pendant trois jours les questions que l'équipe pose réellement, avec les mots employés ; triez-les en sept sections au plus et nommez un responsable par section et par page ; écrivez les quinze premières pages à partir de ce qui existe déjà — la réponse dans le chat, le compte rendu de réunion, le fichier — avec un modèle d'une page comprenant une réponse courte, des étapes, des exceptions et une date de relecture ; épinglez l'index des sections là où l'équipe lit. Entretenez ensuite la boucle : toute question répondue deux fois devient une page, et le responsable de chaque page la relit à sa date.

Que doit contenir un wiki interne ?

Une page par question, chacune avec la question dans les mots que les gens emploient, un responsable, la date de dernière relecture et celle de la prochaine, une réponse courte, les cas où elle s'applique et ceux où elle ne s'applique pas, les étapes nommant le système ou la personne concernée, la décision derrière la règle avec sa date, les exceptions et qui en décide, des liens vers les fichiers en vigueur, et des liens vers les pages liées. Le wiki dans son ensemble a besoin d'une structure de sept sections au plus, organisée selon les questions posées plutôt que par service, et d'un index des sections épinglé là où l'équipe lit.

Quel est le meilleur outil pour un wiki interne ?

Celui que l'équipe ouvre déjà chaque jour, parce qu'un wiki dans un cinquième outil avec son propre login est le wiki que personne ne consulte le lundi. Dans Microsoft Teams, les pages et les fichiers se trouvent dans le canal et son site SharePoint, avec les notes de réunion sous forme de composant Loop ; dans Slack, un canvas dans le canal ; dans Google Workspace, un Google Doc lié depuis le calendrier ; dans WhatsApp, la conversation de groupe elle-même — chacun avec les limites documentées dans le tableau ci-dessus, et chacun gardant la page dans la langue où elle a été saisie. InterMIND garde les notes, les fichiers, le chat et les comptes rendus de réunion d'une équipe dans un seul canal, lus par chaque membre dans sa propre langue, à côté de ces outils plutôt qu'à leur place.

Peut-on construire un wiki interne dans Microsoft Teams ?

D'après la documentation de Microsoft, les fichiers d'une équipe sont stockés dans un site SharePoint créé avec l'équipe, tous les canaux standard partageant ce site avec un dossier par canal ; l'onglet Fichiers du canal est donc l'endroit où vivent les documents du wiki ; les notes de réunion sont un composant Loop que tout participant ou organisateur peut modifier, enregistré automatiquement et accessible depuis le calendrier Teams et le compte rendu de la réunion. Deux limites documentées comptent pour un wiki : les participants externes ne peuvent ni accéder aux notes de réunion ni les modifier, et les conversations et messages de canal peuvent être supprimés après un délai par une stratégie de rétention Teams, tandis que les fichiers suivent leurs propres stratégies SharePoint et OneDrive (pages vérifiées en octobre et novembre 2026).

Comment tenir un wiki interne à jour ?

Avec un responsable et une date de relecture sur chaque page, et rien d'autre. Le travail du responsable est de répondre à « est-ce toujours juste ? » une fois par trimestre et de changer la date ; une page dont le responsable est parti reçoit un nouveau responsable ou sort du wiki. Deux habitudes alimentent les pages : toute réponse donnée deux fois dans le canal de l'équipe devient une page, écrite par celui qui a répondu, et toute décision qui modifie une règle est consignée d'abord, afin que la page puisse renvoyer vers la raison du changement. Un wiki tenu ainsi s'enrichit d'une page chaque fois qu'une question reçoit une réponse, et personne ne le réécrit comme un projet.

Sources : Microsoft Learn — Teams and SharePoint integration ; Microsoft Learn — Learn about retention for Teams ; Microsoft — Take meeting notes in Microsoft Teams ; Microsoft — Translate a message in Microsoft Teams ; Microsoft — Use live captions in Microsoft Teams meetings ; Slack — Pricing ; Slack — Customize data retention in Slack ; Slack — Export your workspace data ; Slack — Meeting agenda template (canvas) ; Google Chat — Use Automatic Translation in Chat ; Google Meet — "Take notes for me" in Google Meet ; Google Meet — Use translated captions ; WhatsApp — How to export your chat history ; WhatsApp — Privacy policy ; WhatsApp blog — Introducing message translations. La page Microsoft Learn sur Teams et SharePoint a été vérifiée en novembre 2026 ; les pages Microsoft sur la rétention Teams et les notes de réunion, la page du modèle de canvas Slack et la page Google « Take notes for me » en octobre 2026 ; les pages Microsoft sur la traduction des messages et les sous-titres Teams, les pages Slack sur les tarifs, la rétention et l'export, les pages Google sur la traduction dans Chat et les sous-titres Meet, ainsi que les pages WhatsApp en août 2026. Les éditeurs modifient avec le temps leurs offres, leurs fonctions et leurs listes de langues ; consultez leurs pages pour connaître l'état actuel.