Une grande partie des premières discussions sur l’IA portait sur ses capacités. Peut-elle écrire ceci, résumer cela, produire du code ou construire une page ?

Nous savons désormais que, souvent, oui.

Ce qui m’intéresse davantage, c’est ce qui se passe lorsque l’IA commence à intervenir dans le processus autour de cette production. Elle sélectionne des informations, les classe, met des fichiers à jour, configure des systèmes, déploie des éléments et surveille ce qui se passe ensuite. Dans les workflows plus avancés, elle conserve aussi le contexte : décisions antérieures, historique du projet, contraintes, hypothèses et éléments appris en cours de route.

Utile, évidemment. Mais le risque change de place.

Si l’IA rédige un mauvais paragraphe, l’erreur se trouve dans ce paragraphe. Quelqu’un la verra peut-être, ou pas, mais au moins on sait à peu près où regarder.

Si elle enregistre une fausse hypothèse comme contexte de projet, cela devient plus intéressant. L’analyse suivante peut s’appuyer dessus. Le prochain texte aussi. Un autre agent peut la retrouver deux semaines plus tard et la traiter comme un fait déjà établi.

L’erreur est remontée en amont.

Une erreur ne reste plus cantonnée à une seule production. Elle peut se retrouver dans tout ce qui vient après.

Conserver le contexte ne suffit pas à le garder vrai

Enregistrer du contexte devient assez facile.

Le garder à jour ne l’est pas.

Les projets changent de manière très ordinaire. Une limite budgétaire ferme en mars est renégociée en juin. Une contrainte chez un fournisseur disparaît. Une remarque formulée pendant un appel exploratoire s’avère n’avoir jamais été une décision. Et parfois, la décision confirmée d’hier n’est tout simplement plus celle d’aujourd’hui.

Le document n’a peut-être pas changé. La réalité, si.

Un système d’IA qui travaille à partir de ce document continuera volontiers sur cette base.

C’est l’une des raisons pour lesquelles je me méfie de la « mémoire » présentée comme une fonctionnalité en soi. Une mémoire n’est utile que si l’on sait exactement ce qui a été mémorisé.

Prenons une phrase assez innocente :

Le client veut X.

Très bien. Sauf que : qui l’a dit ? Le client ? Était-ce mon interprétation ? Une suggestion qui a traversé trois réunions sans jamais être réellement approuvée ? Quand a-t-elle été consignée, et est-elle encore valable ?

Un système de contexte peut conserver tout cela. Mais seulement si nous prenons la peine de conserver, avec l’affirmation, son statut et sa provenance. Sinon, une hypothèse et une décision approuvée peuvent sembler presque identiques lorsqu’elles sont retrouvées plus tard.

Cela devient encore plus important lorsque plusieurs agents travaillent à partir du même contexte. Une mémoire partagée signifie aussi des erreurs partagées.

Parfaitement synchronisées, même.

Je veux savoir quel statut possède une information

Pour le travail concret, quatre niveaux me semblent utiles :

• Production brute — générée, non validée.

• Hypothèse de travail — suffisamment crédible pour être examinée ou utilisée, mais non confirmée.

• Décision confirmée — explicitement approuvée par la personne qui a l’autorité de décider.

• Vérité actuelle du projet — confirmée, traçable et toujours valable aujourd’hui.

La différence entre les deux derniers niveaux paraît minime. Elle ne l’est pas.

Une décision peut avoir été parfaitement réelle et avoir expiré depuis.

Le contexte ne peut donc pas seulement s’accumuler. Certains éléments doivent être remplacés, corrigés, rétrogradés ou simplement marqués comme n’étant plus actuels. Sinon, on finit par avoir une excellente mémoire de plusieurs versions de la réalité en même temps.

Je voudrais aussi que chaque élément important comporte au moins une source, un responsable et une indication de validité.

Rien d’exotique. Juste assez pour répondre à trois questions simples : d’où cela vient-il, qui peut décider si c’est correct, et y croyons-nous encore aujourd’hui ?

Puis vient une deuxième question

Même cela ne représente que la moitié du problème.

Une hypothèse non confirmée n’est pas automatiquement inutile. J’utilise constamment des hypothèses. On peut en analyser une, modéliser un scénario autour d’elle ou s’en servir pour préparer une première version.

Le problème commence lorsque le système oublie qu’il s’agissait d’une hypothèse.

Il y a une différence entre laisser une information incertaine orienter une analyse et lui permettre de modifier quelque chose en dehors de cette analyse.

Un montant budgétaire possible peut être parfaitement utile pour planifier des scénarios. Je préfère qu’un agent ne le publie pas sur un site web.

Une interprétation d’une clause contractuelle peut mériter d’être examinée. Cela n’en fait pas une base appropriée pour envoyer une réponse contraignante.

Une cause technique probable peut orienter un test. Elle ne devrait pas nécessairement déclencher une modification en production.

Il y a donc réellement deux questions dans le workflow :

À quel point sommes-nous certains de cette information ?

Et que lui permettons-nous de faire ?

Pour moi, le véritable modèle ressemble davantage à ceci :

statut de l’information × risque de l’action → contrôle requis

Plus l’action a de conséquences, plus le statut de l’information qui la sous-tend compte.

Les sites web font désormais partie du même problème

Cela change aussi ma manière de voir les sites web.

Ils restent évidemment des interfaces pour les personnes. Mais ils sont de plus en plus lus par des systèmes : moteurs de recherche, assistants IA et agents qui extraient des informations pour les réutiliser ailleurs.

Un site web acquiert donc une autre fonction. Il devient, au moins en partie, une source de référence lisible par les machines.

Une information obsolète n’est dès lors plus seulement un problème de contenu mal tenu.

Une page de service que personne n’a consultée depuis deux ans peut encore être explorée aujourd’hui et traitée comme la position actuelle de l’entreprise. La machine ne sait pas qu’en interne, plus personne ne croit à cette page depuis dix-huit mois.

Aucune astuce GEO intelligente ne résout cela.

La source doit simplement être correcte.

Ce qui nous ramène aux mêmes questions, assez peu glamour : qu’est-ce qui est actuel, qu’est-ce qui fait autorité, qu’est-ce qui a remplacé quoi et qui est responsable de cette information ?

Quelqu’un doit encore décider

Je ne pense pas que chaque entreprise ait soudain besoin d’un « cadre de gouvernance de l’IA ».

Surtout pas d’un document de quarante pages.

Mais dès que des systèmes commencent à entretenir leur propre contexte et à agir à partir de celui-ci, quelqu’un doit décider ce qu’ils sont autorisés à tenir pour vrai.

Un agent peut-il ajouter une information à sa mémoire ? Probablement.

Peut-il décider seul que sa propre interprétation est désormais la vérité du projet ? Autre question.

Peut-il travailler de manière autonome à partir d’une hypothèse ? Parfois.

Cette même hypothèse peut-elle déclencher une publication, un déploiement, un engagement contractuel ou une autre action externe ? Là encore : autre question.

Cette distinction devient plus importante à mesure que les modèles s’améliorent, pas moins.

Parce qu’une meilleure exécution ne corrige pas un mauvais contexte.

Elle ne fait que mieux l’exécuter.

Plus l’IA sait faire de choses, plus nous devons définir soigneusement ce qu’elle est autorisée à croire — et ce qu’elle peut faire de cette conviction.