La tierce maintenance applicative d'une application IA sur mesure, agent, copilote, assistant documentaire, pipeline d'extraction, ne se contracte pas comme celle d'une application classique. Sept clauses manquent aux contrats de TMA habituels : le périmètre de la couche modèle, le rejeu du jeu de test, le suivi du coût d'inférence, les versions du prompt et de l'index, la conduite à tenir quand le fournisseur de modèle change, la réversibilité des données, et le délai de reprise d'un incident dont la cause est une réponse fausse plutôt qu'une panne. Les sept clauses sont détaillées ci-dessous, avec ce que chacune coûte à instruire, et ce qu'il faut réunir avant de confier une application IA à un tiers, que ce soit après le départ du prestataire d'origine ou dès la livraison.
Pourquoi une application IA ne se maintient pas comme un logiciel classique
Un logiciel classique tombe en panne ou fonctionne. Une application IA continue de répondre pendant qu'elle se dégrade : documents périmés dans l'index, questions nouvelles hors du jeu de test, modèle mis à jour par le fournisseur derrière le même nom, coût par requête qui dérive. Aucun de ces cas ne déclenche une alerte de supervision classique, et aucun ne rentre dans la définition habituelle de l'incident. La maintenance doit donc couvrir la qualité des réponses et le coût, pas seulement la disponibilité, ce que décrit l'article sur le LLMOps après la mise en production.
Résumé de la vidéo (en anglais) : IBM Technology explique ce qui distingue l'exploitation d'une application à base de LLM de celle d'un logiciel classique : prompts, données de contexte, évaluation continue et coût, exactement ce qu'un contrat de TMA doit couvrir.
Les sept clauses en un tableau
| Clause | Ce qu'elle fixe | Ce qui manque quand elle est absente |
|---|---|---|
| 1. Périmètre de la couche modèle | Qui est responsable du prompt, de l'index, des outils exposés, du choix du modèle | Un incident de qualité renvoyé entre l'applicatif et « l'IA » sans responsable |
| 2. Rejeu du jeu de test | Fréquence (hebdomadaire le premier trimestre), seuil de baisse qui déclenche une action | La dégradation est découverte par les utilisateurs |
| 3. Suivi du coût d'inférence | Coût par requête et par client, seuil d'alerte, qui paie un dépassement | Une facture de modèle qui double sans explication |
| 4. Versions du prompt, de l'index, du modèle, des outils | Chaque changement numéroté, journalisé, réversible | Un incident qu'on ne peut ni dater ni annuler |
| 5. Changement de fournisseur de modèle | Procédure quand une version est retirée ou tarifée autrement : test, bascule, délai | Une bascule en urgence sans rejeu du jeu de test |
| 6. Réversibilité des données et de l'index | Format d'export des documents, des embeddings, des journaux ; délai de restitution | Un index reconstruit de zéro au changement de prestataire |
| 7. Incident de réponse fausse | Définition, sévérité, délai de prise en compte, qui décide du retrait temporaire | Une réponse fausse chez un client traitée comme une simple demande d'évolution |
Clause 1 : le périmètre de la couche modèle
Un contrat de TMA classique couvre le code, la base de données et l'hébergement. Dans une application IA s'ajoutent le prompt système, l'index documentaire, la liste des outils que l'agent peut appeler et leurs droits, et le choix du modèle chez le fournisseur. Le contrat doit dire qui modifie chacun de ces objets, avec quelle validation, et qui répond quand une réponse est fausse. Sans cette clause, l'applicatif dit que le code fonctionne, et personne ne répond du reste.
Clauses 2 et 7 : la qualité des réponses comme objet du contrat
Le jeu de test, cinquante à deux cents questions réelles avec la réponse attendue, livré avec l'application, devient une obligation contractuelle : rejoué chaque semaine le premier trimestre puis chaque mois, avec un seuil de baisse, par exemple cinq points, qui ouvre un ticket de sévérité définie. Symétriquement, une réponse fausse signalée par un utilisateur est un incident, avec une sévérité selon l'impact (réponse à un client, action exécutée dans un outil, information interne) et un délai de prise en compte. Le mainteneur peut retirer temporairement une fonction, et le contrat dit qui en décide.
Clauses 3 et 5 : le coût et le fournisseur
Le coût d'inférence est une dépense d'exploitation variable, que le mainteneur doit suivre par requête et par client, avec un seuil au-delà duquel il alerte et propose une correction (contexte plafonné, modèle plus léger pour une tâche, itérations d'agent limitées). Le contrat précise qui paie un dépassement causé par un changement non validé. Et quand le fournisseur retire une version de modèle ou change sa tarification, ce qui arrive plusieurs fois par an, la procédure est écrite d'avance : test de la version de remplacement sur le jeu complet, bascule avec numéro de version, délai maximal. Sur les quatre agents livrés à un éditeur SaaS, JUWA a réparti les tâches entre plusieurs modèles hébergés avec un orchestrateur dans la stack du client, précisément pour qu'une bascule de modèle soit une opération courante et non un projet.
Clauses 4 et 6 : versions et réversibilité
Chaque changement de prompt, d'index, de modèle ou d'outil porte un numéro, une date, un auteur et le score du jeu de test avant et après ; c'est ce qui permet de revenir en arrière et de dater un incident. La réversibilité va plus loin que le code : les documents sources, les découpages et les embeddings de l'index, les journaux de requêtes et les versions doivent être exportables dans un format lisible, avec un délai de restitution. Un prestataire qui garde l'index dans un format propriétaire garde le client. Les fiches pratiques IA de la CNIL ajoutent que les journaux contiennent souvent des données personnelles : leur durée de conservation et leur minimisation font partie du contrat.
Ce qu'il faut réunir avant de confier l'application à un tiers
Le code et l'infrastructure, comme pour toute TMA. Plus : le jeu de test et ses derniers scores, le journal des requêtes, la liste des versions en service (prompt, index, modèle, outils), les identifiants et contrats avec les fournisseurs de modèles, la documentation de l'index (sources, découpage, fréquence de mise à jour), et les seuils d'alerte en vigueur. Une application livrée sans jeu de test ni journal demande, avant toute reprise, un audit qui les reconstitue ; c'est le cas le plus fréquent quand le prestataire d'origine est parti, et c'est le premier poste de coût d'une reprise. L'article sur les métriques d'évaluation d'un RAG décrit comment reconstituer un jeu de test à partir des journaux.
Ce que coûte une TMA d'application IA, et pourquoi
Un forfait mensuel qui couvre le rejeu du jeu de test, la lecture des alertes de coût et de transfert, les correctifs et la bascule de version, plus le coût d'inférence refacturé ou payé directement au fournisseur. Le forfait est plus élevé qu'une TMA classique de même taille, parce que la qualité des réponses est surveillée en continu ; il est plus bas qu'une équipe interne à temps partiel qui ne dispose ni du jeu de test ni de l'outillage. Le calcul se fait comme pour tout projet, avec la grille de l'audit IA et de son retour sur investissement : ce que coûte la maintenance contre ce que coûterait une application qui se dégrade sans que personne ne le voie.
Ce qui rend une reprise impossible
Signer une TMA classique pour une application IA, qui couvre la disponibilité et laisse la qualité des réponses sans responsable. Accepter un index dans un format propriétaire, ce qui rend le changement de prestataire équivalent à une reconstruction. Et reprendre une application sans jeu de test ni journal, sans budget d'audit pour les reconstituer.
La TMA JUWA, applicatif et couche IA
La tierce maintenance applicative de JUWA couvre l'applicatif et la couche IA sous un même engagement, avec les sept clauses ci-dessus, trois niveaux de sévérité, le rejeu du jeu de test, le suivi du coût par client et la réversibilité écrite. Pour une application orpheline, la reprise commence par un audit qui reconstitue le jeu de test et le journal, puis un mois de surveillance avant l'engagement de service.
