Maintenance : ce qui occupe l'équipe la deuxième année
ExploitationProductionCoûtMéthode2026-06-0910 min
La deuxième année ressemble peu à la première. Ce qui occupe l'équipe n'est plus la construction mais quatre charges récurrentes que personne n'avait prévues.
Le basculement de la deuxième année
La première année d'un système est consacrée à la construction, la deuxième à l'entretien, et cette bascule n'est presque jamais provisionnée. Elle surprend systématiquement.
Le budget initial couvre le développement, l'intégration et la mise en service. Il s'arrête là. La deuxième année ne fait l'objet d'aucune ligne, alors qu'elle mobilise une charge continue.
Cette charge n'est pas de la correction de défauts : elle vient de l'environnement du système, qui bouge. Le corpus évolue, les modèles sont remplacés, les usages se déplacent, les obligations changent.
Charge un : le corpus qui vieillit
Un corpus indexé une fois répond sur des documents périmés, avec assurance et sans aucun signal d'alerte. C'est la charge la plus lourde et la plus invisible.
Le mécanisme est lent. Une procédure est mise à jour, l'ancienne version reste dans l'index. Un référentiel produit évolue, l'index conserve les références retirées. Six mois plus tard, une part des réponses porte sur un état qui n'existe plus.
Aucun utilisateur ne signale ce type d'erreur, parce qu'elle est indétectable de l'extérieur : la réponse est cohérente, sourcée, et fausse.
La parade est un processus, pas un outil : décider qui signale une mise à jour documentaire, et à quelle fréquence l'index est rafraîchi. C'est un travail d'organisation, prolongement direct de le corpus est le projet.
Les trois autres charges
- Les migrations de modèle, deux à trois fois par an, avec revérification des réglages. Voir ce qu'une génération majeure ne change pas.
- Le diagnostic d'incidents, qui suppose des journaux exploitables et quelqu'un qui sait les lire.
- La dérive des usages : les utilisateurs posent d'autres questions qu'au départ, et le périmètre doit suivre.
- Et une charge de fond : le jeu de tests, qu'il faut alimenter avec les échecs réels sous peine de péremption.
La dérive des usages, la plus intéressante à traiter
Les questions posées dix-huit mois après la mise en service ne ressemblent pas à celles du départ, et c'est un signal, pas un problème. Il faut le lire.
Un système conçu pour retrouver des procédures reçoit progressivement des questions d'interprétation : non plus « que dit la procédure » mais « est-ce que ma situation entre dedans ». C'est une autre tâche, avec un autre risque.
Deux réponses sont possibles et toutes deux légitimes. Élargir le périmètre en connaissance de cause, ce qui suppose de reprendre l'analyse de risque et la fiche du système. Ou refuser explicitement ce type de question et le dire à l'utilisateur.
La mauvaise réponse est de laisser faire. Le système répond alors à une question pour laquelle il n'a été ni conçu, ni testé, ni documenté, la dérive décrite dans écrire la fiche d'un système d'IA.
Lire les questions réelles une fois par trimestre suffit à détecter le déplacement.
Comment rendre cette charge supportable
Quatre rendez-vous par an, une demi-journée chacun, couvrent l'essentiel de l'entretien d'un système documentaire. C'est peu, et c'est ce qui manque.
L'ordre du jour est stable. Rafraîchissement du corpus et vérification des documents modifiés. Rejeu du jeu de tests sur les modèles disponibles, avec décision de bascule. Lecture d'un échantillon de questions réelles pour détecter la dérive. Relecture de la fiche du système.
Ce rituel a une propriété utile : il produit une trace datée des décisions, qui sert à la fois à la conformité et à la personne qui reprendra le système.
Son absence produit le scénario que je rencontre le plus souvent en reprise : un système qui fonctionnait, dont personne ne sait quand il a cessé de fonctionner correctement, et dont plus personne ne connaît les réglages.
L'indicateur qui détecte la dégradation avant les utilisateurs
Le taux de réponses « je ne sais pas », suivi dans le temps. Une baisse soudaine signale souvent que le système s'est mis à répondre là où il refusait, ce qui est une dégradation, pas un progrès.
Ce qu'il faut provisionner dès le premier dossier
Une ligne d'exploitation annuelle, distincte du coût de construction, dans tout dossier d'investissement. C'est le geste qui évite le décrochage de la deuxième année.
L'ordre de grandeur constaté sur les systèmes documentaires que j'exploite : l'entretien annuel représente une fraction significative du coût de construction initial, chaque année, indéfiniment.
Un dossier qui ne mentionne pas cette ligne présente un investissement dont le coût réel sur trois ans est très supérieur à celui annoncé. Il sera arbitré sur un chiffre faux, et la déception arrivera au deuxième exercice.
Mentionner cette ligne a un effet secondaire appréciable : elle oblige à nommer qui assurera l'entretien. Un système sans personne désignée est un système qui se dégradera, quelle que soit sa qualité initiale.
Questions fréquentes
- Qu'est-ce qui occupe l'équipe la deuxième année ?
Le rafraîchissement du corpus, les migrations de modèle deux à trois fois par an, le diagnostic d'incidents et la dérive des usages. Aucune de ces charges n'est de la correction de défauts.
- Pourquoi le corpus qui vieillit est-il si problématique ?
Parce que l'erreur est indétectable de l'extérieur : la réponse est cohérente, sourcée et fausse. Aucun utilisateur ne la signale, et la dégradation s'installe sans qu'on puisse la dater.
- Comment traiter la dérive des usages ?
En lisant un échantillon de questions réelles chaque trimestre. Puis soit élargir le périmètre en reprenant l'analyse de risque, soit refuser explicitement le nouveau type de question. Laisser faire est la mauvaise réponse.
- Que provisionner dans un dossier d'investissement ?
Une ligne d'exploitation annuelle distincte du coût de construction. Sans elle, le coût réel sur trois ans est très supérieur à celui annoncé, et le dossier est arbitré sur un chiffre faux.