IA chez un éditeur de logiciel : le contenu qui se périme, pas le code

Quand un dirigeant cherche « IA éditeur de logiciel PME », il tombe sur des démonstrations de génération de code et sur des promesses de productivité mesurées en pourcentages. Le sujet est réel, il est traité partout, et ce n'est pas là que la petite structure souffre. Dans un éditeur de dix à cent personnes, la douleur est ailleurs : la page d'aide décrit un écran qui n'existe plus, la note de version du mois dernier n'a jamais été écrite, le support répond pour la trentième fois à une question dont la réponse existe quelque part dans un fil interne, et le questionnaire sécurité d'un client grand compte attend depuis trois semaines. Le produit avance à la cadence de l'équipe technique, le contenu avance à la cadence de la personne qui a du temps, c'est-à-dire personne. Ce guide traite ces trois postes, documentation, notes de version et support de niveau 1, avec la méthode et les garde-fous. Et il commence par une mauvaise nouvelle qui est en fait une bonne : deux textes européens viennent de transformer ce retard de contenu en risque de conformité, ce qui est enfin un argument pour y consacrer du temps.

Le produit avance plus vite que ce qui l'explique

Commençons par la santé du secteur, parce qu'elle explique la tension. Sur le marché français du numérique, les éditeurs de logiciels et les plateformes sont le segment qui tire tout le reste : 29,1 milliards d'euros de chiffre d'affaires en 2025 pour une croissance de 8,2 %, et une prévision de 31,6 milliards en 2026 pour 8,4 %, alors que l'ensemble du marché n'est attendu qu'à 4,3 % (étude Numeum et PAC publiée le 19 décembre 2025). Autrement dit : vous croissez deux fois plus vite que l'économie qui vous entoure, avec des équipes qui ne doublent pas.

Cette croissance a un effet secondaire que personne ne budgète. Chaque livraison produit du contenu périmé : un écran qui change invalide une capture, une option renommée invalide un paragraphe d'aide, un correctif non annoncé produit trois tickets, une intégration nouvelle produit une page de documentation qui n'existe pas encore. Ce n'est pas de la dette technique, c'est de la dette de contenu, et elle a la même mécanique : elle ne fait jamais mal le jour où elle se crée. Elle fait mal six mois plus tard, quand un prospect abandonne un essai gratuit faute de trouver comment brancher son outil, quand un client renouvelle en grinçant, ou quand un acheteur demande où est votre documentation de sécurité.

Quatre gisements, dans l'ordre de rentabilité

• Les réponses de support de niveau 1. Les questions dont la réponse existe déjà, écrite dix fois dans dix fils différents. Volume élevé, valeur ajoutée nulle, et c'est le poste qui use le plus vite une équipe.
• La documentation de fonctionnalité. Ce qui manque au moment de la mise en ligne et qui ne sera jamais écrit après, parce que la fonctionnalité suivante est déjà en cours. C'est le gisement dont le rendement est le plus long, et le plus durable.
• Les notes de version. Le poste le plus mal traité de tout le secteur, alors qu'il touche à la fois l'adoption des nouveautés, la réduction des tickets et, depuis cette rentrée, la conformité.
• Les écrits qui sortent du produit. Questionnaires sécurité, réponses à un appel d'offres, argumentaires de fonctionnalité, contenus d'aide traduits. Faible fréquence, enjeu unitaire élevé, et souvent portés par le dirigeant lui-même.

Ce qui ne figure pas dans cette liste compte autant. La génération de code n'est pas traitée ici : elle est abondamment documentée ailleurs, elle relève de vos pratiques d'ingénierie et elle ne se pilote pas comme un sujet de contenu. L'architecture, les choix de conception et la feuille de route ne se délèguent pas davantage. Et la règle générale de sélection reste celle de notre article sur l'automatisation des tâches répétitives : on n'automatise pas ce qui est long, on automatise ce qui est fréquent et sans décision. Sur les quatre gisements ci-dessus, deux sont fréquents et sans décision, un demande un arbitrage éditorial, et le dernier engage l'entreprise.

Avant d'ouvrir le moindre abonnement d'équipe, réglez deux points d'ordre. Le premier est le cadre écrit : ce qui est permis, ce qui ne l'est pas, tenu sur une page selon le modèle de notre article sur la politique IA d'une page. Chez un éditeur, cette page se rédige en une heure et évite trois ans de discussions. Le second est l'existant : dans une équipe technique, l'usage individuel est déjà là depuis longtemps, c'est le shadow AI, et il vaut toujours mieux le cartographier que le découvrir. Commencez par passer les réglages de confidentialité des comptes déjà utilisés, puis posez par écrit à vos fournisseurs les questions à poser avant de signer et gardez les réponses au dossier : vos propres clients vous les poseront à leur tour.

La documentation : de corvée reportée à pièce du dossier

Dans presque tous les éditeurs que compte le pays, la documentation est le premier poste sacrifié. Elle n'a pas de client interne, elle n'a pas de date de livraison, elle ne bloque personne, et elle est donc toujours reportée au sprint suivant. Ce raisonnement vient de perdre sa validité, pour une raison qui n'a rien à voir avec le confort de l'utilisateur.

Le règlement européen sur la cyberrésilience, le règlement (UE) 2024/2847, s'applique aux produits comportant des éléments numériques, ce qui inclut les logiciels. Il est entré en vigueur le 10 décembre 2024, ses obligations de déclaration s'appliquent à partir du 11 septembre 2026, et ses obligations principales à partir du 11 décembre 2027 (page officielle de la Commission européenne). Parmi les obligations du fabricant figurent le fait d'expliquer sa conformité dans la documentation technique, de fournir avec le produit « des informations et des instructions d'utilisation », de définir une période d'assistance qui reflète la durée pendant laquelle le produit est censé être utilisé, et de fournir les mises à jour de sécurité pendant cette période (fiche « Cyber Resilience Act : manufacturers » de la Commission).

Traduisez pour un éditeur de trente personnes : votre documentation utilisateur, la durée pendant laquelle vous vous engagez à corriger, et la manière dont vous informez vos clients cessent d'être des choix commerciaux pour devenir des éléments opposables. La bonne nouvelle est que vous n'avez pas à tout inventer : vous avez déjà la matière, elle est éparpillée dans vos spécifications, vos tickets et vos fils de discussion. Ce qui vous manque est le temps de la mettre en forme, et c'est exactement le travail qu'un assistant fait bien.

La règle d'or : la source de vérité n'est jamais le modèle

Voici la seule chose à retenir de cette section, et elle est plus importante que n'importe quel outil. Un modèle de langue ne sait pas ce que fait votre produit. Il sait à quoi ressemble une documentation de produit, ce qui est très différent et infiniment plus dangereux. Interrogé sur le nom exact d'un paramètre, il en proposera un parfaitement crédible, souvent celui qu'aurait choisi un développeur raisonnable, et parfois exactement le bon, ce qui est le pire des cas parce que cela vous rend confiant. La méthode consiste donc à ne jamais lui demander de savoir, mais uniquement de mettre en forme ce que vous lui donnez : un diff, une spécification, un enchaînement d'écrans décrit, un ticket, un extrait d'interface de programmation.

• Transformer une spécification en page d'aide. Vous fournissez la spécification interne et la liste des écrans ; vous récupérez une page structurée avec le contexte, les prérequis, la procédure numérotée, les cas particuliers et les erreurs fréquentes. Le gain est de l'ordre de deux heures par fonctionnalité.
• Réécrire pour l'utilisateur, pas pour l'auteur. La documentation écrite par la personne qui a développé la fonctionnalité est toujours écrite du point de vue de la fonctionnalité. Un assistant la retourne du point de vue de la tâche que l'utilisateur cherche à accomplir, ce qui est le seul angle qui réduit les tickets.
• Uniformiser une base existante. Cent pages écrites par huit personnes sur six ans n'ont ni le même vocabulaire, ni le même niveau, ni la même structure. La mise au gabarit est un travail mécanique, long et sans décision : c'est le cas d'usage idéal.
• Repérer les trous. Donnez la liste de vos fonctionnalités et la liste de vos pages d'aide ; demandez ce qui n'est couvert nulle part. C'est dix minutes de travail et cela produit systématiquement une liste que personne dans l'équipe n'avait en tête.
• Produire les variantes. La même procédure existe en version courte pour l'écran d'aide contextuelle, en version longue pour la base de connaissances, et en version illustrée pour le courriel d'annonce. Une source, trois formats.

Tu es rédacteur technique pour un éditeur de logiciel. Je te donne la spécification interne d'une fonctionnalité et la description des écrans. Tu rédiges la page d'aide destinée à l'utilisateur final. Tu ne sais rien du produit en dehors de ce que je te donne.

Structure imposée :
1. Titre sous forme de tâche à accomplir, du point de vue de l'utilisateur.
2. En une phrase : à quoi sert cette fonctionnalité et pour qui.
3. Prérequis : droits nécessaires, réglages préalables, formule d'abonnement concernée.
4. Procédure numérotée. Une action par étape. Reprends les libellés EXACTS des boutons et des champs tels que je te les ai donnés.
5. Cas particuliers et limites.
6. Messages d'erreur possibles et ce qu'ils signifient.
7. Pour aller plus loin : liste des pages d'aide connexes que je t'indique, et rien d'autre.

Règles strictes :
- N'invente aucun nom de bouton, de champ, de paramètre, de menu, de valeur par défaut ni de raccourci. Si l'information manque, écris « [À COMPLÉTER : ... ] » avec la question précise.
- N'invente aucune limite chiffrée (quota, taille de fichier, nombre maximum, durée de conservation).
- Ne promets aucun résultat et n'emploie aucun superlatif.
- Vouvoiement, phrases courtes, présent de l'indicatif, une idée par phrase.
- Termine par la liste des points que le relecteur devra vérifier en exécutant la procédure.

Spécification et description des écrans :
[coller ici]

Deux prolongements naturels, une fois la chaîne en place. Le premier est la traduction : un éditeur qui vend hors de France double ou triple son volume de contenu, et la localisation d'une base d'aide est le cas d'usage le mieux maîtrisé de tous, sous réserve de la règle décrite dans notre article sur l'IA et la traduction, à savoir qu'une version fait foi et que les autres en dérivent. Le second est le référencement : la documentation publique d'un éditeur est souvent son meilleur actif d'acquisition, parce qu'elle répond à des questions très précises que personne d'autre ne traite, ce que détaille notre article sur l'IA et le référencement d'un site. Pour la façon d'écrire les instructions elles-mêmes, l'essentiel tient dans notre article sur l'écriture d'un bon prompt : un rôle, un plan imposé, des interdictions explicites. Et rangez ces gabarits au même endroit que le reste, dans une base de connaissances d'équipe, avec vos instructions dans une bibliothèque de prompts partagée, plutôt que dans le poste d'une seule personne.

Les notes de version : au 11 septembre 2026, elles changent de statut

La note de version est le document le plus négligé du secteur et le plus rentable à redresser. Négligé parce qu'il tombe entre deux chaises : trop technique pour le marketing, trop commercial pour l'équipe technique, et jamais assigné à personne. Rentable parce qu'il agit sur trois choses à la fois : l'adoption des nouveautés que vous venez de payer en jours de développement, le volume de tickets de la semaine suivante, et la confiance de vos clients les plus exigeants.

Une échéance vient de le faire passer dans une autre catégorie. À partir du 11 septembre 2026, soit dans moins de trois semaines, les fabricants de produits comportant des éléments numériques doivent signaler les vulnérabilités activement exploitées et les incidents graves affectant la sécurité de leurs produits. Le signalement passe par la plateforme unique de signalement gérée par l'agence européenne de cybersécurité, qui diffuse ensuite aux centres nationaux de réponse aux incidents, le CERT-FR pour la France. L'ANSSI précise les délais : « une alerte précoce dans les 24h et une notification dans les 72h suivant la prise de connaissance » (questions fréquentes sur le CRA, ANSSI). Le reste du dispositif se déploie ensuite par étapes, entre juin 2026 et décembre 2027, la surveillance du marché étant confiée en France à l'ANFR (cadre réglementaire du CRA, ANSSI).

Ne confondez pas les deux circuits, c'est l'erreur la plus coûteuse. Le signalement réglementaire va vers une autorité, dans des délais courts, avec des informations qui ne sont pas publiques. La note de version, elle, va vers vos clients, à votre rythme éditorial. Ce qui change avec cette échéance, c'est que les deux doivent désormais être cohérents et datés : le jour où vous devrez expliquer à un client, ou à une autorité, quand vous avez su, quand vous avez corrigé et quand vous avez prévenu, vos notes de version seront la trace publique de cette chronologie. Une entreprise qui publie « corrections diverses et améliorations » tous les quinze jours n'a aucune trace. Une entreprise qui publie une ligne par correctif, datée et numérotée, en a une.

Une note de version, trois lecteurs

La raison pour laquelle les notes de version sont mal écrites tient en une phrase : on essaie d'en faire un seul texte pour trois publics qui n'ont ni les mêmes questions, ni le même temps. Séparez-les, et l'exercice devient mécanique, donc délégable.

• L'utilisateur. Il veut savoir ce qui change dans son écran et ce qu'il gagne. Deux lignes par nouveauté, écrites comme une tâche, avec un lien vers la page d'aide. Il ne lira jamais un numéro de version.
• L'administrateur qui déploie. Il veut savoir ce qui casse : évolutions de configuration, actions requises avant mise à jour, compatibilité, ruptures d'interface de programmation, ordre des opérations, procédure de retour arrière. C'est la partie que l'on écrit toujours trop tard.
• Le responsable sécurité du client. Il veut la liste des vulnérabilités corrigées, la version qui corrige, la gravité et la conduite à tenir. C'est un document court, factuel, sans adjectif, qu'il archivera. C'est aussi celui qu'un acheteur vous réclamera au moment du renouvellement.

La matière première d'une note de version existe déjà et elle est excellente : le journal des commits, la liste des tickets fermés depuis la dernière livraison, les numéros de version. Le travail consiste à traduire ce langage d'ingénieur en trois textes destinés à trois lecteurs. C'est une transformation, pas une création, et c'est le meilleur usage possible d'un assistant chez un éditeur. Comptez vingt minutes au lieu de deux heures, à condition que la personne qui relit soit celle qui a livré.

Tu es rédacteur technique chez un éditeur de logiciel. Je te donne le journal des commits et la liste des tickets fermés depuis la dernière livraison. Tu produis la note de version en trois blocs séparés, destinés à trois lecteurs différents. Tu ne qualifies rien, tu reformules.

BLOC 1 · Pour les utilisateurs
Pour chaque nouveauté visible dans l'interface : un titre formulé comme une tâche, deux lignes maximum, le bénéfice concret. Pas de numéro de version, pas de vocabulaire technique. Regroupe par zone du produit.

BLOC 2 · Pour les administrateurs
Actions requises avant la mise à jour, changements de configuration, ruptures de compatibilité, évolutions d'interface de programmation avec l'ancien et le nouveau comportement, ordre des opérations, procédure de retour arrière si elle figure dans les éléments fournis.

BLOC 3 · Pour les responsables sécurité
Uniquement les correctifs de sécurité présents dans les éléments fournis : ce qui est corrigé, la version qui corrige, l'action attendue du client. Style factuel, aucun adjectif.

Règles strictes :
- N'invente aucun numéro de version, aucun identifiant de vulnérabilité, aucun niveau de gravité, aucune date. Ces éléments viennent de moi ou de personne.
- N'attribue aucun niveau de criticité de ta propre initiative. Si je ne l'ai pas donné, écris « gravité à qualifier ».
- Ne décris jamais comment une faille pouvait être exploitée.
- Si un commit est incompréhensible hors contexte, place-le dans une liste finale « à clarifier avant publication » plutôt que de deviner.

Journal des commits et tickets fermés :
[coller ici]

Le support de niveau 1 : dire que c'est une machine, et savoir passer la main

Le support est le poste où la tentation est la plus forte et où les échecs sont les plus visibles. Tout le monde a en tête le robot qui répond à côté pendant trois échanges avant de proposer un lien vers une page qui n'existe plus. Ce n'est pas une fatalité, c'est la conséquence directe d'une décision : avoir branché un robot sur une documentation en retard. Un assistant de support ne peut pas être meilleur que le contenu sur lequel il s'appuie, ce qui explique pourquoi cette section vient après celle sur la documentation, et pas avant.

L'obligation de transparence est entrée en application

Commençons par le cadre, parce qu'il est récent et qu'il est simple à respecter. Les règles de transparence du règlement européen sur l'intelligence artificielle s'appliquent depuis août 2026. Le principe posé par la Commission tient en une phrase : « les humains devraient être informés qu'ils interagissent avec une machine afin de pouvoir prendre une décision en connaissance de cause » (cadre réglementaire de l'IA, Commission européenne, page mise à jour le 3 août 2026). Les obligations les plus lourdes, celles des systèmes à haut risque, ont été repoussées au 2 décembre 2027, mais la transparence, elle, n'a pas bougé : le détail des dates réellement applicables est dans notre article sur le calendrier de l'AI Act après le Digital Omnibus.

En pratique, pour un éditeur, cela se règle en une demi-journée de développement : une phrase d'accueil qui dit clairement que l'interlocuteur est un assistant automatique, un moyen visible et permanent de demander un humain, et une mention dans vos conditions et votre page de confidentialité. Ce n'est pas une contrainte commerciale, c'est même l'inverse : les utilisateurs pardonnent une réponse imparfaite d'un robot annoncé, et ne pardonnent pas d'avoir été trompés sur la nature de leur interlocuteur.

La question que presque personne ne se pose : le sous-traitant ultérieur

Voici le point qui distingue un éditeur de logiciel de toutes les autres PME, et que les articles génériques sur l'IA n'abordent jamais. Vos clients vous confient leurs données, et parfois celles de leurs propres clients. Dans le vocabulaire du RGPD, vous êtes le plus souvent leur sous-traitant. Le jour où vous branchez un modèle de langue sur vos tickets, sur vos journaux applicatifs ou sur votre base de connaissances alimentée par des échanges clients, vous ne faites pas qu'ajouter un outil : vous ajoutez un sous-traitant ultérieur dans une chaîne contractuelle qui ne vous appartient pas.

La CNIL décrit les deux régimes possibles dans ses clauses types. Avec une autorisation générale, le sous-traitant « informe préalablement et par écrit le responsable de traitement de tout changement envisagé » concernant l'ajout ou le remplacement d'autres sous-traitants, en précisant les activités concernées, l'identité du nouveau sous-traitant et les dates du contrat, le responsable de traitement disposant d'un délai minimum pour présenter ses objections. Avec une autorisation spécifique, il faut « recueillir l'autorisation écrite, préalable et spécifique du responsable de traitement » pour chaque nouveau prestataire. Dans les deux cas, le sous-traitant initial « demeure pleinement responsable devant le responsable de traitement de l'exécution par l'autre sous-traitant de ses obligations » (exemples de clauses de sous-traitance, CNIL).

Ce que cela veut dire concrètement, en trois gestes : relisez ce que vos propres contrats clients prévoient (la plupart des contrats d'éditeur contiennent une autorisation générale, vérifiez-le), tenez à jour une liste publique de vos sous-traitants ultérieurs sur votre site, et prévenez vos clients avant l'ajout, en respectant le délai d'objection prévu. Un éditeur qui branche un modèle sur les tickets pendant un week-end et le découvre au premier audit d'un grand compte perd bien plus de temps qu'il n'en a gagné.

Le brouillon assisté avant le robot autonome

Pour un éditeur de moins de cinquante personnes, l'ordre de déploiement qui marche est presque toujours le même, et il est contre-intuitif : commencez par assister vos agents, pas par remplacer la première ligne. L'assistant lit le ticket, retrouve les passages pertinents de votre documentation, propose un brouillon de réponse avec les liens, et l'agent envoie après relecture. Vous gagnez la moitié du temps de traitement, vous ne prenez aucun risque de réponse fausse envoyée seule, et surtout vous mesurez : chaque correction que fait l'agent vous dit exactement où votre documentation est trouble.

Le robot en autonomie sur le canal public vient après, quand trois conditions sont réunies : votre base d'aide est à jour, l'assistant ne répond que sur elle, et il passe la main dès qu'il ne trouve pas. Un déflecteur honnête qui répond à 30 % des demandes et transfère proprement les 70 % restantes vaut mieux qu'un bavard qui répond à tout. Mesurez deux chiffres et deux seulement : la part de conversations résolues sans intervention humaine, et la part de conversations reprises par un humain après un échange raté. Le second chiffre est celui que personne ne publie et c'est le seul qui compte. Le fonctionnement de ces briques est décrit dans notre article sur les agents IA, et la méthode générale du poste dans celui sur l'IA au service client.

Un dernier usage, discret et très rentable chez un éditeur : la synthèse hebdomadaire des tickets. Regrouper les demandes de la semaine par thème, sortir les cinq sujets les plus fréquents et les rapprocher de la feuille de route est un travail que personne n'a le temps de faire à la main, et c'est la meilleure source d'idées produit qui existe. Même mécanique que celle de notre article sur les comptes rendus automatiques, appliquée à une file de tickets. Si vos utilisateurs s'expriment aussi en public, la logique de réponse aux avis est traitée dans notre article sur les avis clients.

Une précision de vocabulaire pour finir, parce qu'elle a des conséquences. Le règlement européen sur l'IA ne traite pas de la même façon celui qui fournit un système et celui qui l'utilise : les déployeurs assurent la surveillance humaine, les fournisseurs doivent notamment disposer d'un système de surveillance après commercialisation. Tant que vous utilisez un assistant en interne, vous êtes du côté de l'utilisateur. Le jour où vous intégrez une brique d'IA dans votre produit et où vous la vendez sous votre marque, la question de votre qualification se pose sérieusement, et elle vaut une heure avec votre conseil. Les usages qui basculent en haut risque sont listés dans notre article sur les usages à haut risque de l'annexe III : la plupart des fonctionnalités d'un logiciel de gestion n'y figurent pas, mais le tri de candidatures, la notation de personnes et l'évaluation de solvabilité y figurent, et beaucoup d'éditeurs en vendent sans le savoir.

Quatre semaines pour installer la méthode, sans ralentir les livraisons

Un éditeur n'a pas besoin d'un projet de transformation, il a besoin que la prochaine livraison sorte avec sa documentation. La seule installation qui tient est celle qui se glisse dans un rythme existant, celui des sprints, avec une mesure avant et après. Une demi-journée par semaine pendant quatre semaines suffit.

Semaine 1 : mesurer la dette de contenu. Trois chiffres, pas plus. Le nombre de pages d'aide dont la dernière vérification remonte à plus de six mois. La part des tickets du mois dernier dont la réponse existait déjà quelque part par écrit. Le délai médian de première réponse au support. Ajoutez la liste des fonctionnalités livrées cette année sans page d'aide : elle fait toujours mal, et c'est le but. Sans ces chiffres, aucun calcul de retour ne sera honnête dans six mois, comme le rappelle notre article sur le retour sur investissement de l'IA en PME.

Semaine 2 : écrire la frontière. Une page. Ce qui ne sort jamais de l'entreprise (données clients, secrets d'exploitation, dépôts privés), la règle des libellés et des valeurs jamais générés, l'interdiction d'un engagement dans une réponse de support, la règle de qualification des vulnérabilités, et la position sur les sous-traitants ultérieurs. Cette page se montre à un prospect qui remplit son questionnaire sécurité, et elle vous fait gagner un cycle de vente entier.

Semaine 3 : construire la source de vérité. C'est l'investissement qui rapporte le plus longtemps. Un gabarit de page d'aide, un gabarit de note de version à trois blocs, un gabarit d'avis de sécurité, un glossaire produit qui fixe le nom officiel de chaque objet de votre logiciel (c'est le document le plus sous-estimé d'un éditeur : sans lui, trois personnes appellent la même chose de trois façons et votre assistant héritera de la confusion), et la liste à jour de vos sous-traitants. À partir de là, un contenu se compose au lieu de s'écrire.

Semaine 4 : passer une vraie livraison à la méthode et nommer un responsable. Prenez la prochaine version, produisez sa documentation depuis la spécification, sa note de version depuis le journal des commits, et faites exécuter chaque procédure par quelqu'un qui ne l'a pas développée. Mesurez le temps, gardez les corrections : elles nourrissent vos gabarits. Puis désignez la personne qui tient la page de règles et répond aux questions. Dans un éditeur de trente personnes, c'est un rôle de deux heures par mois, décrit dans notre article sur le référent IA. Sans ce rôle, l'usage retombe en six semaines et vous aurez juste ajouté un abonnement.

L'obligation de compétence, elle, est déjà là

Une obligation que beaucoup d'éditeurs découvrent tard, alors qu'elle est applicable depuis février 2025 : le règlement européen sur l'IA demande aux organisations qui déploient ces systèmes de veiller à un niveau suffisant de maîtrise de l'IA chez les personnes qui les utilisent pour leur compte. Ce n'est pas une certification à acheter, c'est une compétence à démontrer, et elle se démontre par des traces : une page de règles, une session d'une heure, une liste de présence. Le détail est dans notre article sur la formation obligatoire à l'IA. Pour un éditeur, cette exigence a un effet secondaire utile : elle vous force à écrire ce que vous faites, ce qui est précisément ce que vos clients grands comptes vous demanderont au prochain audit.

Ce que vous obtenez au bout de quatre semaines n'est ni une documentation parfaite ni un support entièrement automatisé. C'est plus modeste et plus solide : chaque livraison sort avec sa page d'aide et sa note de version à trois blocs, les procédures publiées ont été exécutées par quelqu'un, les tickets répétitifs reçoivent une réponse appuyée sur un contenu à jour, le questionnaire sécurité du prochain grand compte se remplit en deux heures au lieu de trois semaines, et vous avez une trace datée de ce que vous avez publié et quand. La logique d'ensemble du poste est reprise dans notre parcours service client, la question de la rédaction elle-même dans notre article sur l'IA et la rédaction. Le reste est une affaire de régularité : chez un éditeur, ce qui n'entre pas dans la définition de « terminé » n'est jamais fait.

Questions fréquentes