La dette technique invisible de l'IA
Le concept de dette technique existe depuis longtemps en développement logiciel : c'est le coût caché des raccourcis pris pour aller vite, qu'on paie plus tard sous forme de bugs, de maintenance difficile et de systèmes fragiles. Avec l'IA, cette dette prend des formes nouvelles — et souvent plus sournoises.
Une étude académique publiée sur ArXiv (PromptDebt) a analysé la dette technique spécifique aux applications basées sur des LLMs. Les chercheurs ont identifié trois catégories de dette propres à ces systèmes : la dette liée aux prompts (instructions mal structurées, choix de paramètres non documentés), la dette liée aux frameworks d'orchestration (dépendances à des outils comme LangChain qui évoluent rapidement), et la dette liée aux coûts opérationnels (gestion des tokens, choix de modèles). Leur conclusion est frappante : une fois que cette dette apparaît dans un projet LLM, elle a tendance à persister. Le couplage étroit entre prompts, API et couches d'orchestration crée un verrouillage architectural qui rend la refactorisation coûteuse.
Victor Holmin, dans une analyse sur la dette technique des applications LLM, résume bien le problème : beaucoup d'organisations se précipitent pour intégrer des LLMs dans leurs workflows sans feuille de route pour la durabilité à long terme. Le résultat, ce sont des correctifs ad hoc, des solutions de contournement et des assemblages bricolés qui résolvent les problèmes immédiats mais accumulent des inefficacités au fil du temps.
Ce que ça signifie pour une PME
Quand un projet IA est développé dans l'urgence — ce qui est souvent le cas —, les choix techniques (quel modèle, quels prompts, quelle architecture, quels paramètres) restent dans la tête du développeur qui les a faits. Si cette personne part, le projet devient une boîte noire. Pas parce que la technologie est mystérieuse, mais parce que personne n'a pris le temps d'écrire le « pourquoi » des décisions.
Documenter une IA, ce n'est pas documenter du code classique
La documentation d'un logiciel traditionnel se concentre sur la logique du code : quelles fonctions font quoi, comment les modules s'articulent, quelles sont les dépendances. Pour un système IA, c'est nécessaire mais insuffisant. Il faut aussi documenter des éléments qui n'existent pas dans le développement classique.
Selon Trail ML, la documentation agit comme une fondation pour des systèmes IA de qualité. Elle permet de retracer les décisions de développement, de faciliter la collaboration entre parties prenantes, d'assurer un onboarding fluide des nouveaux membres de l'équipe, et de préparer la conformité réglementaire. L'absence de bonne documentation crée des goulets d'étranglement coûteux — pertes d'efficacité liées au travail redondant, trop de réunions pour reconstituer le contexte, ou amendes pour non-conformité.
Trail ML recommande de structurer la documentation d'un projet IA en quatre blocs :
Le charter du projet : ce que le système est conçu pour faire, ses usages prévus (et ses usages non prévus), les parties prenantes responsables, et les métriques d'évaluation retenues.
La documentation des données : quelles données sont utilisées, pourquoi elles ont été choisies, comment elles ont été préparées, et quelles sont leurs limites connues. C'est ce qu'on appelle parfois les « data cards » — des fiches descriptives qui accompagnent chaque jeu de données.
La documentation du modèle et des prompts : quel modèle est utilisé, pourquoi celui-là plutôt qu'un autre, quels sont les prompts en production (avec leur historique de versions), quels paramètres ont été choisis (température, nombre de tokens, etc.) et quel est le raisonnement derrière ces choix.
La documentation du système : comment les différentes briques s'articulent — le modèle, les bases de données, les API, les outils d'automatisation, les flux de données. C'est la carte d'ensemble qui permet de comprendre l'architecture.
Ce que ça signifie pour une PME
Vous n'avez pas besoin de rédiger un mémoire technique. Mais exigez de votre prestataire — ou documentez vous-même si vous développez en interne — au minimum : la liste des outils et modèles utilisés (avec leurs versions), les prompts en production et la raison de leur formulation, les données sur lesquelles l'IA s'appuie, et un schéma simple du flux de traitement. Ce document, même court, est ce qui permet à quelqu'un d'autre de reprendre le projet.
La documentation continue, pas le PDF de fin de contrat
Un piège fréquent : traiter la documentation comme un livrable de fin de projet. On développe, on met en production, et à la toute fin on rédige un document récapitulatif. Le problème, c'est que ce document est déjà obsolète au moment où il est écrit — parce que les systèmes IA évoluent en permanence.
Le CSIRO (l'organisme de recherche scientifique australien) a formalisé un pattern de « documentation continue » spécifiquement pour les systèmes IA. Leur constat : le développement de systèmes IA est souvent rapide et expérimental, et les développeurs priorisent le code plutôt que la documentation. La solution est d'intégrer la documentation dans le cycle de développement lui-même — pas de la reporter à la fin. Ils recommandent l'utilisation de templates standardisés (model cards, datasheets, factsheets) qui sont mis à jour à chaque itération.
Le CLeAR Framework, développé par le Shorenstein Center de l'université Harvard, propose quatre principes pour une documentation IA efficace : elle doit être Comparable (permettre la comparaison entre systèmes), Lisible (compréhensible par des non-spécialistes), Actionnable (utile pour prendre des décisions concrètes) et Robuste (capable d'évoluer dans le temps sans devenir obsolète). Les auteurs insistent sur le fait que la documentation doit être obligatoire dans la création, l'utilisation et la vente de systèmes IA.
Ce que ça signifie pour une PME
Si vous travaillez avec un prestataire, intégrez la documentation dans les livrables de chaque itération — pas comme un bonus à la fin du contrat. À chaque modification significative (changement de modèle, modification d'un prompt, ajout d'une source de données), le document doit être mis à jour. C'est un investissement de temps modeste qui protège une valeur considérable.
Un projet IA réussi est un projet réversible
L'idée centrale de cet article tient en une phrase : un projet IA bien fait est un projet que quelqu'un d'autre peut reprendre.
C'est ce qu'on appelle la réversibilité — la capacité de changer de prestataire, d'intégrer un nouveau développeur, ou de faire évoluer le système en interne sans repartir de zéro. Et la réversibilité repose presque entièrement sur la qualité de la documentation.
Les recherches sur la dette technique des LLMs le confirment : le couplage étroit entre prompts, API et frameworks d'orchestration crée un verrouillage qui rend le changement coûteux. Mais ce verrouillage n'est pas inévitable. Il est le résultat de choix non documentés — des raccourcis pris dans l'urgence dont personne n'a noté la raison ni les alternatives.
En documentant le « pourquoi » des choix techniques (pourquoi ce modèle, pourquoi cette architecture, pourquoi cette formulation de prompt) autant que le « comment », on transforme un projet IA d'une dépendance à une personne en un actif de l'entreprise. Le système, ses règles et son historique deviennent une propriété intellectuelle exploitable — pas un savoir enfermé dans la tête d'un seul développeur.
Ce qu'il faut retenir
La documentation d'un projet IA n'est pas un exercice bureaucratique. C'est une assurance contre la perte de contrôle sur un outil que votre entreprise utilise au quotidien. Voici les principes clés :
- Documentez les décisions, pas seulement le code. Le « pourquoi » d'un choix de modèle ou d'un prompt est plus précieux que le code lui-même — parce que c'est ce qui permet de refaire un choix différent demain.
- Documentez en continu, pas à la fin. Chaque modification significative doit être tracée au moment où elle est faite. Un document rédigé six mois après les faits est un exercice de fiction.
- Utilisez des templates simples. Un charter de projet, des fiches de données, un registre de prompts versionnés, et un schéma d'architecture. Quatre documents courts valent mieux qu'un rapport exhaustif que personne ne lira.
- Pensez au prochain. La personne qui reprendra le projet n'a pas assisté aux réunions, n'a pas vu les tests échouer, n'a pas entendu les discussions sur les compromis. Écrivez pour elle.
Un projet IA qui ne peut survivre qu'avec son créateur original n'est pas un projet réussi — c'est une dépendance déguisée en solution.
Sources
- PromptDebt: A Comprehensive Study of Technical Debt Across LLM Projects — ArXiv
- Documenting AI Systems for Collaboration & Governance — Trail ML
- Continuous Documentation Using Templates — CSIRO
- The CLeAR Documentation Framework for AI Transparency — Shorenstein Center, Harvard
- Addressing Technical Debt in LLM-Powered Applications — Victor Holmin