Pendant trois ans, la réponse à un projet IA décevant était toujours la même : attendre le prochain modèle. Elle a longtemps été juste. Elle ne l'est plus. Sur l'immense majorité des cas d'usage que nous déployons, extraction, classification, synthèse, rédaction assistée, réponse sur base documentaire, les modèles disponibles aujourd'hui dépassent largement le niveau requis.
Le facteur limitant a changé de nature. Il ne se trouve plus chez le fournisseur, il se trouve dans l'entreprise. Nous l'appelons la dette de contexte.
Une notion empruntée à la dette technique
La dette technique désigne l'ensemble des raccourcis accumulés dans un système informatique, qu'il faudra bien payer un jour, avec intérêts. La dette de contexte désigne autre chose : tout ce que votre entreprise sait faire sans l'avoir jamais écrit.
Les règles qui n'existent que dans la tête de trois personnes. Les exceptions que l'on applique sans les avoir formalisées. Les critères d'arbitrage entre deux options, qui varient selon le client et que personne ne saurait énoncer. Les seuils implicites, ceux à partir desquels un dossier remonte à la direction. Et cette phrase que nous entendons dans chaque atelier : « on fait comme ça, c'est tout ».
Tant que le travail est fait par des humains, cette dette reste invisible. Un collaborateur expérimenté absorbe l'ambiguïté sans même la percevoir. Il comble les trous du processus avec son jugement, et personne ne mesure la quantité de décisions qu'il prend chaque jour sans les nommer. Confiez la même tâche à un système, et la dette devient soudainement visible, parce qu'un système ne comble rien.
Comment elle se manifeste dans un projet
- La démonstration fonctionnait parfaitement, la production donne des résultats erratiques sur les cas réels
- La réponse produite est juste, mais inutilisable en l'état, sans que personne ne sache expliquer pourquoi
- L'équipe itère indéfiniment sur les instructions, avec le sentiment de tourner en rond
- Chaque relecture par un expert métier fait apparaître un « oui mais dans ce cas-là, on fait autrement »
- Chaque nouveau lot de documents rouvre la spécification que l'on croyait close
Ces symptômes sont systématiquement attribués à la technologie. Ils relèvent en réalité d'un déficit d'énoncé : le système fait exactement ce qu'on lui a dit, et ce qu'on lui a dit est incomplet parce que l'entreprise ne se l'était jamais formulé à elle-même.
Pourquoi elle est devenue le facteur limitant
Deux évolutions se sont croisées. D'un côté, la qualité des modèles progresse à un rythme qui ne vous coûte rien : vous en bénéficiez sans effort, simplement en changeant de version. De l'autre, la dette de contexte ne se rembourse que par un travail délibéré, que personne d'autre que vous ne peut faire à votre place.
L'écart entre les deux courbes s'est inversé quelque part en 2025. C'est ce qui explique un phénomène troublant : deux entreprises du même secteur, équipées des mêmes outils, obtiennent des résultats séparés par un facteur cinq. L'écart ne vient pas de la technologie, à laquelle elles ont un accès identique.
On croit souvent que l'agrandissement des fenêtres de contexte va régler le problème. C'est un contresens : on ne peut pas coller dans un contexte ce qui n'a jamais été écrit nulle part. Une fenêtre d'un million de tokens ne sert à rien si le savoir tient dans des conversations de couloir.
Trois formes de dette de contexte
Les distinguer est utile, parce qu'elles ne se remboursent pas de la même manière.
- Les règles non écrites : le savoir existe, il est simplement resté oral. C'est la forme la plus facile à traiter, et souvent la plus volumineuse
- Les données non qualifiées : les documents existent mais rien n'indique lesquels font autorité, lesquels sont périmés, ni ce qu'est une bonne réponse. Il n'existe aucune référence à laquelle comparer une sortie
- Les décisions jamais prises : l'organisation n'a en réalité jamais tranché. L'ambiguïté était absorbée par les humains, et la question remonte au grand jour dès qu'il faut l'écrire. C'est la forme la plus coûteuse, parce qu'elle exige un arbitrage de direction et non un travail de documentation
La troisième catégorie est celle qui fait échouer les projets. Un système ne peut pas trancher à la place d'une organisation qui ne s'est pas décidée. Quand un projet IA s'enlise sur un point technique apparemment mineur, il faut presque toujours chercher une décision de gestion qui n'a jamais été prise.
Comment on la rembourse
Il n'existe pas de raccourci, mais il existe une méthode, et elle est plus rapide qu'on ne le croit. Elle repose sur un principe simple : observer le travail réel plutôt que le processus décrit.
- S'asseoir à côté des personnes qui font la tâche, et regarder, plutôt que de leur demander de décrire leur processus. L'écart entre les deux est le gisement
- Capter les arbitrages, pas seulement les étapes. La question utile n'est pas « que faites-vous » mais « à quoi voyez-vous qu'il faut faire autrement »
- Écrire les exceptions en premier. Le cas nominal est facile à documenter, ce sont les exceptions qui portent la valeur métier
- Constituer un jeu de trente à cinquante cas réels avec la réponse attendue, validée par un expert. C'est le seul moyen de rendre l'exigence de qualité mesurable
- Transformer les règles en artefacts durables : instructions system, skills, procédures versionnées. Une règle qui reste orale n'a pas été remboursée
Le jeu de cas est l'étape que les équipes veulent systématiquement sauter, et c'est celle qui produit le plus de valeur. Sans référence, toute discussion sur la qualité reste une affaire d'impressions, et l'on ne sait jamais si une modification améliore le système ou le dégrade ailleurs.
“Un projet IA ne bute presque jamais sur ce que le modèle ne sait pas faire. Il bute sur ce que l'entreprise n'a jamais écrit.”
Le bénéfice dépasse largement l'IA
C'est l'argument qui emporte la décision en comité de direction. Rembourser sa dette de contexte produit des bénéfices qui existeraient même si le projet IA était abandonné en cours de route.
Des règles écrites survivent au départ d'un collaborateur clé. Un nouvel arrivant devient autonome en semaines plutôt qu'en trimestres. Les arbitrages implicites remontent à la surface et se discutent enfin. Et ce corpus de règles, d'exceptions et de cas de référence constitue un actif propre à l'entreprise, que ses concurrents n'ont pas et ne peuvent pas acheter.
Le bon ordre
L'erreur consiste à commencer par les outils, parce que c'est la partie visible et rassurante. Le bon ordre est inverse : choisir un processus, mesurer sa dette de contexte, la rembourser sur ce périmètre restreint, puis outiller. Un processus dont les règles sont écrites s'outille en quelques semaines. Un processus dont les règles sont tacites peut absorber des mois sans jamais atteindre la production.
C'est précisément pourquoi notre méthode commence par l'écoute plutôt que par la technologie. Ce temps n'est pas une politesse commerciale avant les choses sérieuses : c'est là que se joue la faisabilité réelle du projet, et c'est là que se mesure la dette qu'il faudra rembourser.