Récemment, mon tableau de bord de supervision est resté figé pendant trois jours. Les erreurs applicatives de mes projets y sont affichées en continu, agrégées toutes les heures. Pendant trois jours, la tuile a montré des chiffres parfaitement crédibles. Ils dataient de trois jours plus tôt.
Le service de monitoring, lui, n’avait jamais cessé de répondre. Les données étaient là, disponibles, à un appel d’API de distance. Ce qui était tombé, c’est le morceau que j’avais glissé au milieu du tuyau : une session d’IA.
Une panne silencieuse, la pire catégorie
Le détail qui rend l’histoire désagréable n’est pas la panne. C’est qu’elle ne ressemblait pas à une panne.
Un agent qui plante affiche une erreur, remonte une alerte, se voit. Ici, l’agent horaire échouait proprement, sans rien écrire, et la page continuait de servir le dernier état connu avec sa mise en forme habituelle. Rien ne clignotait. J’ai découvert le problème en cherchant autre chose.
La cause était banale : l’authentification de l’outil en ligne de commande qui portait la session avait expiré. Pas de quota dépassé, pas de modèle indisponible, pas de mauvaise réponse. Juste un jeton périmé sur un composant dont je n’avais jamais considéré qu’il faisait partie de ma chaîne de collecte.
Pourquoi l’IA était là au départ
Par facilité, et c’est le point intéressant.
L’accès au monitoring existait déjà sous forme d’outil branché à mon assistant. Écrire un prompt du type « récupère les erreurs non résolues, classe-les, écris la synthèse » prend dix minutes et fonctionne du premier coup. Écrire le client d’API équivalent, gérer la pagination, les champs, les cas limites, ça prend une demi-journée et ça ne produit aucune démo impressionnante.
Le choix était donc rationnel à l’instant où je l’ai fait. Il l’était beaucoup moins un mois plus tard, quand ce raccourci était devenu un maillon de production sur lequel reposait la seule vue que j’avais de la santé de mes applications.
C’est un schéma que je vois beaucoup en ce moment dans les entreprises qui « mettent de l’IA » dans leurs process. Le prototype est spectaculaire, la mise en production est indolore, et personne ne repasse derrière pour se demander ce qui se passe le jour où le composant le plus récent et le moins déterministe de la chaîne ne répond plus.
Le correctif, deux cents lignes ennuyeuses
Le remplacement fait environ deux cents lignes de Python. Il lit l’API REST du service de monitoring avec un jeton dédié, filtre les projets qui ne me concernent pas, applique une classification par mots-clés et écrit le résultat. Aucune IA sur le trajet.
Le modèle n’a pas disparu pour autant, il a changé de place. Le tri fin, la formulation d’un diagnostic, la décision de créer ou non une tâche : ça reste une couche au-dessus, qui peut échouer sans conséquence. Si elle ne tourne pas, je perds du commentaire. Avant, je perdais la donnée.
La différence tient en une phrase : la vérité affichée sur mon tableau de bord ne dépend plus de l’état d’authentification d’un assistant.
Ce n’était pas le premier avertissement
Quelques semaines plus tôt, l’agent qui surveille les autres agents s’était mis à m’envoyer des alertes de panne pour des services qui allaient très bien. La raison : il calculait lui-même l’horodatage courant, et le modèle se trompait de journée dans certains créneaux horaires. Huit fausses alertes avant que je comprenne.
Le correctif a été de lui interdire de produire une date. Une date se demande au système d’exploitation, elle ne se déduit pas.
Là encore, la leçon n’est pas « l’IA est peu fiable ». Elle est plus précise : un modèle de langage est non déterministe par construction, et c’est exactement ce qu’on lui demande quand on veut de la reformulation, du résumé ou de l’arbitrage. Le problème n’apparaît que si on lui confie en plus des tâches où le non déterminisme est un défaut : compter, dater, additionner, aller chercher une valeur qui existe déjà quelque part.
La règle que j’applique maintenant
Mon système personnel compte aujourd’hui quarante-huit agents actifs. Vingt-neuf d’entre eux ne contiennent aucune IA. Ce sont des scripts : ils lisent une API, calculent, écrivent un fichier, envoient une notification. Ils tournent à l’heure, ils coûtent zéro, et leur mode de défaillance est lisible.
Les dix-neuf autres utilisent un modèle parce qu’ils font quelque chose qu’un script ne sait pas faire : lire une conversation client et en sortir une intention, rédiger un brouillon, hiérarchiser des signaux hétérogènes, proposer trois options et en recommander une.
La frontière que je trace est là. L’IA au-dessus du système, pour le jugement. Jamais dedans, sur le chemin d’acquisition ou de calcul de la donnée.
La question à poser avant d’en mettre partout
Pour un dirigeant qui évalue une automatisation avec de l’IA dedans, la question utile n’est pas « est-ce que ça marche en démo ». C’est celle-ci, en deux temps.
Si le modèle est indisponible pendant trois jours, qu’est-ce qui s’arrête exactement ? Et est-ce que quelqu’un le voit, ou est-ce que l’écran continue d’afficher des chiffres qui ont l’air normaux ?
Si la réponse à la seconde partie est floue, le problème n’est pas l’IA. C’est qu’on a ajouté une dépendance sans lui appliquer les exigences qu’on applique à toutes les autres : détection de panne, mode dégradé explicite, et une hypothèse claire sur ce qui se passe quand elle n’est pas là.
Une automatisation qui ne sait pas dire qu’elle est en panne n’est pas une automatisation, c’est un affichage.
Si vous avez un process où de l’IA s’est installée sans qu’on ait vraiment tracé cette frontière, on peut regarder ensemble ce qui mérite d’y rester et ce qui gagnerait à redevenir un script.