Pendant des années, lorsque l’on parlait de dette technique, l’image la plus répandue était presque toujours la même : des systèmes hérités, un code difficile à maintenir, des modules fortement couplés, l’absence de tests, une base de données mal modélisée et des décisions anciennes qui paient aujourd’hui leurs intérêts.
Ce type de dette continuera d’exister. Mais une nouvelle couche est en train de se former dans de nombreuses entreprises, et elle est peut-être encore plus difficile à voir.
La dette des agents d’IA.
Créer un agent est devenu relativement facile. Relier un modèle à des outils, des bases internes, des API, des documents et des flux de travail n’exige plus l’effort d’ingénierie qu’il y a quelques années. En peu de temps, une unité peut concevoir un assistant qui interroge des données, résume des documents, met à jour des enregistrements, génère des réponses, ouvre des tickets ou suggère des décisions.
Le problème est que mettre un agent en fonctionnement n’est que le début.
Il sera difficile d’expliquer, d’auditer et de contrôler ce qu’il a fait une fois qu’il sera connecté au cœur de l’activité.
La prochaine grande dette technique des entreprises ne résidera peut-être pas dans le code héritée, mais dans les agents d’IA créés sans gouvernance.
Les agents ne sont pas que des chatbots au nom accrocheur
Une erreur courante consiste à traiter tout agent d’IA comme s’il ne s’agissait que d’une interface conversationnelle plus sophistiquée. Cela minimise le risque.
Un chatbot traditionnel répond. Un agent opérationnel peut aller plus loin : interpréter le contexte, décider des prochaines étapes, appeler des outils, consulter des systèmes, générer des artefacts et exécuter des actions.
Cette différence change tout.
Quand un agent ne répond qu’à une question générale, le risque se concentre principalement sur la qualité de la réponse. Lorsqu’un agent accède à un CRM, consulte des données financières, ouvre des tickets, active des API, modifie un statut ou crée des documents officiels, il cesse d’être une interface et devient un composant opérationnel.
À ce moment-là, les questions changent :
- Quels systèmes peut-il accéder ?
- Avec quelles permissions ?
- Quelles données entrent dans le contexte ?
- Quelles actions peut-il exécuter seul ?
- Quand doit-il être approuvé ?
- Qui audite ce qu’il a fait ?
- Qui répond lorsque il se trompe ?
Ce ne sont pas des questions philosophiques. Ce sont des questions d’architecture.
La nouvelle dette technique invisible
La dette technique classique laisse généralement des traces relativement visibles. Duplication de code, tests manquants, dépendances anciennes, déploiement fragile, architecture fortement couplée. C’est problématique, mais au moins elle apparaît souvent pour l’ingénierie.
La dette des agents d’IA peut être plus silencieuse.
Elle se manifeste sous des formes telles que :
- Prompts sans versionnage
- Outils connectés sans ownership clair
- Autorisations trop larges
- Mémoire sans politique définie
- Journaux insuffisants
- Décisions difficiles à reproduire
- Agents créés par des services différents sans standard
- Intégrations avec des données sensibles sans révision
- Absence de piste d’audit
Au début, tout semble productif. L’agent aide. L’équipe gagne en rapidité. La démonstration impressionne. Mais avec le temps, les questions difficiles apparaissent.
Pourquoi a-t-il répondu cela ? Quel document a-t-il utilisé ? Quelle outil a-t-il appelé ? Qui a approuvé cette action ? Cette donnée pouvait-elle entrer dans le contexte ? Cette autorisation devrait-elle exister ? Cette version du prompt était-elle déjà en production ?
Si l’entreprise ne peut pas répondre, la dette commence déjà à s’accumuler.
Le risque n’est pas seulement que l’IA se trompe
Beaucoup de discussions autour de l’IA se concentrent encore trop sur l’erreur de la réponse. C’est important, mais incomplet.
Dans un environnement d’entreprise, le risque majeur peut ne pas résider uniquement dans l’erreur de l’IA. Il s’agit aussi de l’impossibilité pour quelqu’un d’expliquer pourquoi elle s’est trompée, quel contexte elle a utilisé, quel outil elle a appelé et quel impact opérationnel cela a produit.
Imaginez un agent de service qui consulte les politiques internes, l’historique du client et le système de commandes. Il répond avec assurance, mais en utilisant une politique obsolète. Le client reçoit une recommandation erronée. Le service client enregistre la décision. Un autre système traite alors le dossier comme résolu.
Où est l’erreur ?
Dans le modèle ? Dans l’invite ? Dans la base de connaissances ? Dans l’outil ? En l’absence de validation ? En l’absence de propriétaire du contenu ? Avec des autorisations trop larges ? En l’absence d’audit ?
Sans traçabilité, l’incident devient du brouillard.
Et les systèmes critiques ne peuvent pas opérer dans le brouillard.
Gouvernance des agents commence par des limites
La première couche de gouvernance n’est pas sophistiquée. Elle est simple : fixer des limites.
Un agent d’entreprise doit avoir des frontières claires :
- Ce qu’il peut accéder
- Quelles outils il peut appeler
- Quelles données il peut utiliser
- Quelles actions il peut exécuter
- Quelles actions nécessitent une validation humaine
- Quand doit-il escalader à une personne
- Quels contextes sont hors périmètre
- Quels journaux doivent être préservés
Un exemple conceptuel :
{
"agent": "sales-assistant",
"tools": [
"crm.search_leads",
"crm.update_status",
"email.create_draft"
],
"requires_human_approval": [
"email.send",
"crm.delete_lead"
]
}Ce type de définition semble simple, mais elle prévient déjà une série de problèmes. L’agent peut aider l’équipe commerciale à consulter et préparer des informations, mais il ne doit pas exécuter des actions sensibles sans approbation.
La question n’est pas « est-ce que l’agent peut faire ? ». La question est « devrait-il pouvoir le faire ? ».
Des autorisations trop larges constituent un appel à la dette
L’un des risques les plus courants dans les projets internes d’IA est d’octroyer des permissions trop larges pour accélérer la preuve de concept. En phase expérimentale, cela peut sembler pratique. En production, cela devient un risque.
Des autorisations trop larges créent des agents qui :
- accèdent à plus de données que nécessaire
- appellent des outils hors du contexte exact
- exécutent des actions sensibles sans contrôle
- génèrent des réponses sur la base d’informations inappropriées
- élèvent l’impact en cas de défaillance
Cela ressemble énormément à des problèmes classiques de sécurité des API et des systèmes internes. La différence, c’est qu’avec les agents, le chemin entre l’intention de l’utilisateur, l’interprétation du modèle et l’action exécutée peut être plus difficile à auditer.
C’est pourquoi le principe du moindre privilège doit être appliqué tôt.
Un agent financier qui résume des rapports ne devrait peut-être pas effectuer des paiements. Un agent RH qui répond à des questions ne devrait peut-être pas modifier les données salariales. Un agent d’assistance qui consulte une commande ne devrait peut-être pas émettre un remboursement sans approbation.
Sans ces frontières, l’entreprise ne crée pas une automatisation intelligente. Elle crée une zone grise opérationnelle.
Observabilité pour les agents d’IA
Si les agents commencent à exécuter une partie du travail, ils doivent aussi être observables.
Il ne suffit pas de savoir qu’un appel au modèle a eu lieu. Il faut comprendre tout le flux :
- Quel utilisateur a déclenché l’action
- Quelle intention a été identifiée
- Quel contexte a été utilisé
- Quelles outils ont été appelés
- Quelles données ont été consultées
- Quelle réponse a été générée
- Quelle action a été exécutée
- S’il y a eu une approbation humaine
- Quel a été le coût et la latence
- S’il y a eu fallback ou erreur
Un journal d’audit pourrait enregistrer quelque chose comme :
{
"agentId": "sales-assistant",
"userId": "u-123",
"tool": "crm.update_status",
"input": {
"leadId": "lead-789",
"status": "qualified"
},
"approval": "auto",
"timestamp": "2026-07-13T10:00:00Z"
}Ce type de traçabilité modifie la conversation. Sans elle, l’agent devient une boîte noire au sein de l’opération. Avec elle, il devient possible d’établir une base pour l’enquête, l’audit et l’amélioration continue.
Bien sûr, les journaux d’IA exigent une attention à la vie privée, aux données sensibles et à la rétention. Mais l’alternative, ne rien enregistrer d’utile, serait pire.
Prompts aussi nécessitent un cycle de vie
Une autre source de dette invisible consiste à traiter le prompt comme un texte isolé.
Dans de nombreux projets, les prompts démarrent dans des prototypes, des documents, des tickets, des variables d’environnement ou des configurations peu gouvernées. Lorsque l’agent évolue, personne ne sait exactement quelle version est en production, pourquoi une instruction a changé ou quelle modification a provoqué un comportement inattendu.
Si l’agent exécute une tâche pertinente, le prompt devient une partie de la logique du système.
Et la logique du système nécessite un cycle de vie :
- Versionnage
- Révision
- Test
- Historique
- Environnement de validation
- Approbation pour production
- Rollback
Ce n’est pas parce que le prompt est rédigé en langage naturel qu’il cesse d’être un composant technique. Dans les agents d’IA, il influence le comportement autant que le code, la configuration ou la règle métier.
Mémoire sans politique devient un risque
Beaucoup d’agents deviennent plus utiles lorsqu’ils parviennent à garder le contexte. Mais une mémoire dépourvue de politique claire est un autre point de dette.
L’entreprise doit définir :
- Ce qui peut être stocké
- Pour combien de temps
- Qui peut accéder
- Comment supprimer
- Comment auditer
- Ce qui ne doit jamais entrer en mémoire
- Comment séparer mémoire personnelle, mémoire d’équipe et mémoire organisationnelle
Sans cela, la mémoire de l’agent peut mélanger contexte obsolète, données sensibles, décisions anciennes et préférences qui ne devraient plus influencer les réponses.
Le problème n’est pas d’utiliser la mémoire. Le problème est de la traiter comme de la magie, et non comme un stockage d’informations ayant un impact opérationnel.
Ownership : qui est le propriétaire de l’agent ?
Cette question semble simple, mais beaucoup d’entreprises ne savent pas y répondre.
Qui est le propriétaire d’un agent d’IA ?
- L’équipe qui l’a créé ?
- Le domaine métier qui l’utilise ?
- L’ingénierie de plateforme ?
- La sécurité ?
- Les données ?
- Le produit ?
La réponse peut varier, mais elle ne peut pas être “personne”.
Un agent en production a besoin d’un ownership explicite. Quelqu’un doit répondre pour :
- Évolution
- Révision des autorisations
- Qualité
- Incidents
- Coûts
- Audit
- Documentation
- Mise à la retraite
Sans propriétaire, l’agent devient une automatisation orpheine. Et l’automatisation orpheine est l’une des formes les plus dangereuses de dette technique.
Un cadre pratique avant de mettre des agents en production
Si l’organisation souhaite utiliser des agents avec sérieux, ces questions devraient être posées avant l’emballement final.
1. Cet agent ne fait-il que répondre ou exécute-t-il des actions ?
La différence détermine le niveau de risque.
2. Quels systèmes accède-t-il ?
Tout système connecté agrandit la surface opérationnelle.
3. Quelles données entrent dans le contexte ?
Le contexte définit le comportement. Des données sensibles ou obsolètes peuvent mener à de mauvaises décisions.
4. Existe-t-il une piste d’audit ?
Si l’on ne peut pas reconstruire ce qui s’est passé, l’agent ne devrait pas exécuter des actions critiques.
5. Y a-t-il des limites claires sur l’action ?
Sans limites, l’autonomie devient un risque.
6. Existe-t-il un fallback humain ?
Les flux critiques nécessitent une escalade et une intervention humaine.
7. Prompts et outils ont-ils un versionnage ?
Sans versionnage, il n’existe pas une véritable gouvernance du changement.
8. Existe-t-il un owner clair ?
Sans propriétaire, l’agent peut même fonctionner, mais il ne devrait pas être traité comme un composant fiable.
Cet cadre n’élimine pas tous les risques, mais il sépare déjà expérimentation et architecture de production.
La séniorité réside dans la gouvernance, pas seulement dans l’adoption
La prochaine phase de l’IA dans les entreprises ne sera pas remportée par ceux qui créent simplement encore plus d’agents. Elle sera remportée par ceux qui sauront les intégrer en sécurité, avec du contrôle et une clarté opérationnelle.
Cela nécessite une mentalité plus proche de l’architecture que de la démonstration.
Les agents d’IA doivent être pensés comme des composants du système :
- Avec des contrats
- Avec des limites
- Avec l’observabilité
- Avec le versionnage
- Avec l’ownership
- Avec l’audit
- Avec le cycle de vie
Quand cela ne se produit pas, l’entreprise peut gagner en productivité à court terme. Mais elle accumule une dette difficile à payer par la suite.
Conclusion
Le problème ne sera pas de mettre l’IA en fonctionnement. Cela devient plus facile chaque mois. Le vrai défi sera de la mettre sous contrôle avant qu’elle ne devienne une couche opaque de l’architecture d’entreprise.
Les agents d’IA peuvent générer une valeur énorme. Mais, lorsqu’ils sont connectés à des outils, des données et des flux réels, ils cessent d’être de simples assistants et deviennent des composants opérationnels.
Et les composants opérationnels nécessitent une gouvernance.
La prochaine grande dette technique peut ne pas être le code final visible. Peut-être sera-ce l’ensemble des agents, prompts, mémoires, autorisations et outils que personne n’arrive à auditer correctement.
Demandez aujourd’hui s’il existe une piste d’audit, une limite d’action et un mécanisme d’intervention pour tout agent d’IA en production.
