64 % de mes agents IA étaient déjà obsolètes — et je ne le savais même pas

Il y a deux semaines, j'ai audité mon infrastructure Claude Code. J'ai compté mes agents IA, analysé lesquels étaient encore utilisés, lesquels avaient été remplacés, lesquels n'avaient jamais été exécutés.

Le résultat : 64 % de mes agents étaient en mode legacy. Obsolètes. Créés, oubliés, accumulés comme des brouillons dans un tiroir.

Et pourtant, ils occupaient toujours de la mémoire, du contexte, de la RAM vectorielle. Ils ralentissaient les recherches sémantiques. Ils polluaient les suggestions du routeur d'agents. Ils existaient — mais plus personne ne savait pourquoi.

Ce chiffre m'a forcé à affronter une évidence : je n'avais aucun système pour tracer mes propres créations.

Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.

Le problème qu'on ne voit pas venir

Ces deux dernières années, l'IA a changé la vitesse à laquelle on produit du code et des automatisations. GitHub Copilot génère aujourd'hui 46 % du code de ses utilisateurs en moyenne. Les développeurs complètent leurs tâches 55 % plus vite. Des projets qui prenaient une semaine se construisent en une journée.

C'est formidable. Et c'est exactement là que le problème commence.

Parce que la vitesse de création n'est pas le problème. La vitesse d'obsolescence, oui.

L'IA évolue si vite qu'un outil novateur à l'instant t devient souvent dépassé à l'instant t + quelques semaines. Un modèle lancé en janvier est supplanté en mars. Une approche de prompting optimale en 2024 est contredite par les nouvelles capacités de 2025. Un agent créé pour compenser une limitation technique d'un modèle devient inutile dès que cette limitation disparaît.

Gartner a mis des chiffres sur ce phénomène. En juillet 2024, ils ont prédit que 30 % des projets GenAI seraient abandonnés après le proof of concept d'ici fin 2025. La réalité a dépassé la prédiction : 42 % des entreprises ont effectivement abandonné la majorité de leurs initiatives IA en 2025 — contre 17 % seulement un an plus tôt.

Ces projets abandonnés ne disparaissent pas proprement. Ils laissent des résidus : des scripts, des agents, des configurations, des dépendances. Et sans système de tracking, ces résidus s'accumulent silencieusement.

Ce que j'ai trouvé dans ma propre infrastructure

Voici les chiffres concrets de mon audit du 28 mars 2026 :

Sur 95 fichiers agents présents sur disque :
- 27 sont actifs et utilisés quotidiennement
- 49 n'ont pas été accédés depuis plus de 60 jours
- 14 agents Svelte5 ont été créés mais jamais exécutés une seule fois
- 10 project-agents RAG ont été construits selon un pattern qui n'est plus utilisé depuis des mois

Et ce n'est pas le plus frappant. Le plus frappant, c'est que ces 49 agents legacy continuaient de peser sur le système : dans les recherches vectorielles, dans les suggestions du routeur, dans la RAM PostgreSQL. Chaque requête sémantique parcourait 76 agents pour en utiliser 27.

Je ne savais pas qui était qui. Je ne savais pas ce qui était encore pertinent. Je ne savais pas ce que j'aurais pu supprimer sans casser quelque chose.

C'est exactement la définition de la dette technique.

Pourquoi ça arrive — et pourquoi c'est structurel

La dette technique IA n'est pas un problème de discipline personnelle. C'est un problème structurel lié à la nature même de l'IA générative.

Forrester a été explicite là-dessus en octobre 2024 :

"Plus de 50 % des décideurs technologiques verront leur dette technique atteindre un niveau modéré ou élevé en 2025."

Et cette tendance n'est pas en train de se corriger. Elle s'accélère. Le même rapport projette 75 % en 2026.

Pourquoi ? Trois mécanismes s'alimentent mutuellement :

1. La création est découplée de la maintenance.
Avec l'IA, créer un agent, un script, une automatisation prend quelques minutes. Le créer est trivial. Le documenter, l'inventorier, le tester, comprendre ses dépendances — ça prend beaucoup plus de temps. Donc on crée, et on reporte le reste à plus tard. Sauf que "plus tard" n'arrive jamais, parce qu'entre-temps on a déjà créé trois autres choses.

2. Les dépendances sont invisibles et dangereuses.
Endor Labs a analysé les dépendances générées par les assistants IA en 2025 : 49 % des versions importées contiennent des vulnérabilités connues, et 34 % des dépendances recommandées sont hallucinées — elles n'existent pas. Sans tracking, ces dépendances fantômes s'accumulent dans vos projets sans que personne ne les revoie jamais.

3. Le code IA se duplique au lieu de se refactoriser.
GitClear a analysé 211 millions de lignes modifiées chez Google, Microsoft et Meta. Résultat : le code "copy/paste" a dépassé le code refactorisé pour la première fois de l'histoire en 2024. Le refactoring est passé de 25 % à moins de 10 % des modifications. L'IA optimise pour la création rapide, pas pour la maintenabilité.

Ces trois mécanismes combinés produisent un effet prévisible : une infrastructure qui grossit vite, mal tracée, et qui accumule des objets dont la pertinence n'est jamais révisée.

Le vrai coût de ne pas tracker

On pourrait penser que des scripts abandonnés, ça n'a pas de coût. Qu'ils sont là, inertes, sans impact.

Ce n'est pas vrai.

Coût cognitif. Quand vous ne savez plus ce qui existe, vous recréez ce qui existe déjà. Ou vous évitez de toucher à ce que vous ne comprenez plus. Les deux produisent de la duplication et de la frilosité.

Coût de performance. Dans mon cas, 49 agents obsolètes participaient à chaque recherche vectorielle. Chaque requête de routage parcourait un corpus gonflé de résultats non pertinents.

Coût de sécurité. Gartner prédit que les "prompt-to-app" citizen developers augmenteront les défauts logiciels de 2500 % d'ici 2028. Des scripts non tracés sont des scripts non audités. Des dépendances non inventoriées sont des dépendances non patchées.

Coût décisionnel. Si vous ne savez pas ce qui est actif, vous ne savez pas ce que vous pouvez supprimer, ce que vous pouvez remplacer, ce qui nécessite une mise à jour. Votre capacité à prendre des décisions architecturales s'effondre.

Ce qu'une plateforme de tracking doit faire

Après cet audit, j'ai réfléchi à ce que j'aurais voulu avoir depuis le début. Pas un outil de plus à maintenir, mais une couche d'observabilité native sur mes scripts et agents.

Voici les cinq capacités essentielles :

1. Inventaire automatique à la création
Chaque nouveau script, agent ou automatisation devrait être enregistré automatiquement avec ses métadonnées : date de création, auteur, contexte d'usage, dépendances déclarées. Pas de saisie manuelle — si c'est manuel, ça ne sera pas fait.

2. Tracking d'usage en temps réel
Quand est-ce que ce script a été exécuté pour la dernière fois ? Combien de fois par semaine ? Quel agent l'appelle ? Ces métriques permettent de distinguer ce qui est vivant de ce qui est en coma artificiel.

3. Graphe de dépendances
Ce script appelle quoi ? Qui l'appelle ? Si je modifie cette fonction, qu'est-ce que ça casse ? Un graphe de dépendances navigable — même simple — est la différence entre une modification sereine et une modification à l'aveugle.

4. Détection automatique de l'obsolescence
Aucun accès depuis 30 jours ? Dépendance dont la version a 18 mois de retard ? Agent dont le modèle cible a été déprécié ? Ces signaux doivent déclencher des alertes automatiques, pas des audits manuels trimestriels.

5. Cycle de vie documenté
Actif / peu actif / legacy / archivé / supprimé. Un statut visible, modifiable, et qui génère des rappels. Un script sans statut est un script dont personne n'est propriétaire.

Ce que ça change concrètement

Dans mon infrastructure, j'ai mis en place cette logique via une combinaison de tables PostgreSQL (rag_agent_instructions avec last_accessed_at, saliency_score, dormant), de crons qui détectent le dernier usage, et de tableaux de bord qui montrent l'état du système en temps réel.

L'audit du 28 mars — le même qui a révélé les 64 % legacy — a pris moins d'une heure parce que ces données existaient. Avant ce système, il m'aurait fallu parcourir manuellement des dizaines de fichiers sans garantie d'exhaustivité.

La différence entre "je sais ce qui est vivant" et "je suppose que ça tourne encore" est exactement la différence entre une infrastructure maîtrisée et une dette technique qui grossit en silence.

Le signal d'alerte pour votre organisation

Si vous utilisez des outils IA pour accélérer votre développement — et c'est très probablement le cas — posez-vous trois questions :

1. Savez-vous combien de scripts IA ou d'automatisations existent dans votre organisation aujourd'hui ?
2. Savez-vous lesquels ont été utilisés ce mois-ci ?
3. Savez-vous quelles dépendances ces scripts utilisent, et si elles sont à jour ?

Si vous ne pouvez pas répondre avec confiance aux trois, vous avez déjà de la dette technique IA qui s'accumule. La question n'est pas de savoir si elle va poser problème — c'est de savoir quand.

Gartner estime que 40 % des entreprises utilisant des outils de codage IA à la consommation feront face à des coûts imprévus dépassant 2 fois leur budget d'ici 2027. Une part significative de ces coûts viendra de projets abandonnés qu'on n'a pas traité à temps.

L'IA vous donne une vitesse de création sans précédent. Mais sans observabilité sur ce que vous créez, vous construisez sur du sable. Chaque sprint vous rapproche du moment où vous ne saurez plus ce que vous avez.

La plateforme de tracking n'est pas un luxe. C'est le fondement qui rend l'accélération IA durable.

Articles liés :

- RTK : l'outil qui m'a révélé combien mes commandes gaspillaient de tokens

- Monitoring RAG et conscience d'optimisation

- Fusion d'appels fonction : tokens, latence et oublis

Qui suis-je ?

Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.

J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.

Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.

L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.

La technologie, les méthodes, le management sont le cœur de mes compétences.

Vous pouvez me faire confiance sur ces points là.

Si vous voulez me parler d'un de vos projets, n'hésitez pas à m'envoyer un email avec vos disponibilités à : contact@mathieugrenier.fr

Tous les articles de ce blog sont écrits par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100 % IA.

Sources : Gartner (juillet 2024, février 2025, décembre 2025), Forrester (octobre 2024), Endor Labs State of Dependency Management 2025, GitClear AI Code Quality Research 2025, GitHub Copilot Statistics 2025.