Mesurer un projet IA en production : le voyant vert qui mentait

Le voyant vert pendant la panne

Sur Livia, le produit que je construis, un battement de cœur (un signal envoyé à intervalle régulier pour dire « je suis vivant ») affichait « tout va bien » pendant que la passerelle IA, le point de passage vers le modèle d’IA, était en panne. Pendant ce temps, l’IA ne répondait plus à personne.

Le signal venait d’un composant en vie. Il ne vérifiait pas que le trajet complet fonctionnait. J’ai corrigé la mesure, puis fixé des seuils.

Un tableau de bord interne répond à une question : mes composants fonctionnent-ils entre eux ? Votre client pose une autre question : ma demande aboutit-elle ? Les deux réponses divergent dès qu’un maillon de la chaîne casse sans que les autres le sachent.

Dans le cas de Livia, tout répondait vu de l’intérieur. Le réseau interne confirmait que chaque service était joignable. La panne se trouvait ailleurs, à la passerelle IA, et seul un appel venu de l’extérieur pouvait la voir.

Je connais cette famille de mensonge. Dans l’intégration d’une IA à un logiciel métier, j’ai décrit le jour où une API a renvoyé « tout va bien » avec l’erreur cachée dans le corps de la réponse. Le code de statut était bon, le contenu était faux.

Deux questions, dans cet ordre : est-ce que ça tourne, est-ce que ça rend le temps promis

Après la mise en production, un projet IA se juge sur deux questions. La première : le système tourne-t-il ? La seconde : rend-il le temps que le business case annonçait ?

L’ordre compte. Un système en panne ne rend aucun temps, et le chiffre du mois en souffre sans que personne comprenne pourquoi. Je vérifie donc la santé d’abord. Le ROI se lit ensuite, sur un système dont je sais qu’il a tourné.

Pour le pilotage de chaque semaine (part traitée sans intervention, part corrigée, délai, coût), j’utilise quatre chiffres ; ils n’ont de sens que sur un système dont la santé est vérifiée.

Mesurer la santé depuis l’adresse du client

Sur Livia, la sonde vise l’adresse HTTPS publique, celle que le client utilise. Elle emprunte le même chemin que lui : internet, le certificat, le serveur, puis la passerelle IA. Si un maillon casse, la sonde casse avec lui.

Un « signal valide » désigne une vraie réponse, obtenue de bout en bout, passerelle IA comprise. Un simple « le serveur répond » ne suffit pas. Le battement de cœur de l’histoire du début répondait lui aussi, et c’est lui qui mentait.

Cela change ce que vous demandez à un prestataire. Posez la question : d’où part la mesure, et que traverse-t-elle ? Exigez qu’elle parte de l’adresse publique et envoie une vraie requête qui traverse tout le trajet.

Décider des seuils avant la panne

Une sonde qui détecte une panne ne sert à rien si personne n’a décidé quoi faire ensuite. Sur Livia, j’ai fixé les seuils d’avance : après 15 minutes sans signal valide, un bandeau s’affiche côté client. Après 30 minutes, une alerte interne part.

Le bandeau prévient le client en premier. Il sait que le problème est identifié et il peut s’organiser. L’alerte interne vient ensuite, quand l’incident dure assez pour demander une intervention.

Illustration : une conciergerie de 120 logements confie à un agent IA la préparation des réponses aux messages des voyageurs. Un samedi soir, l’agent tombe. Sans alerte, les messages attendent jusqu’au lundi, et les voyageurs arrivés ce week-end se débrouillent seuls. Avec ces deux seuils, le bandeau apparaît au bout de 15 minutes et l’alerte part au bout de 30 : quelqu’un s’en occupe le soir même. J’ai détaillé les messages de nuit dans l’article sur l’IA en conciergerie.

Le chiffre qui rembourse : le temps rendu

Reste la seconde question. Je la tranche par un chiffre : le temps rendu, relevé sur le même volume qu’avant le projet, puis comparé à ce que le business case annonçait. Sans le même volume, la comparaison ne vaut rien.

Illustration : la même conciergerie reçoit 900 messages de voyageurs par mois. À la main, chaque message demande 4 minutes, soit 60 heures par mois. Avec un agent IA qui prépare les réponses, la relecture prend 1 minute par message, soit 15 heures. Le temps rendu atteint donc 45 heures par mois.

Le business case de cette illustration annonçait 40 heures rendues par mois. La mesure du premier mois, sur le même volume, en montre 45. L’écart tombe du bon côté, mais il compte dans les deux sens : un chiffre mesuré sous l’annonce ouvre une discussion, un chiffre au-dessus confirme la méthode.

Avant de démarrer, j’applique une règle déjà publiée sur ce site : si l’investissement ne se rembourse pas en moins de douze mois de gain mesuré, je ne lance pas.

Ce qu’un prestataire doit vous montrer après la mise en production

Six questions à poser au premier bilan, et même avant de signer.

1. D’où part la mesure de santé : de l’adresse publique que mes clients utilisent, ou de votre réseau interne ?
2. Qu’appelez-vous un signal valide : une vraie réponse de bout en bout, ou un simple « le serveur répond » ?
3. Quels seuils déclenchent un bandeau côté client et une alerte interne, et qui reçoit cette alerte ?
4. Pouvez-vous me montrer la dernière panne détectée, et en combien de temps vous l’avez vue ?
5. Quel est le temps rendu mesuré le mois dernier, sur le même volume qu’avant le projet ?
6. Comment cet écart se compare-t-il au business case, et que faites-vous quand il est négatif ?

La grille par où commencer aide à poser ces questions avant même de choisir un prestataire. Pour regarder votre cas ensemble, le point de départ dure trente minutes, gratuites, sans engagement : je chiffre avec vous ce qu’un projet vous rendrait et ce que je mesurerais pour le vérifier.