PAPIER A · IA EN PRODUCTION
Pourquoi 88 % des pilotes IA meurent — et le protocole des 12 %
La réunion où ça meurt
La réunion où un projet d'IA meurt ne s'appelle jamais « réunion d'annulation ».
Elle s'appelle « point d'avancement ». Il y a huit personnes, la démo a été faite il y a quatre mois, tout le monde avait applaudi. Cette fois, quelqu'un de la DSI pose une question qui n'est pas hostile, juste précise : « quand l'agent envoie un mail à un client, on le retrouve où ? »
Silence. Puis la conformité enchaîne : « et vos données de test, elles venaient d'où ? »
Personne ne dit non. Personne ne dit oui non plus. Le projet passe en « à consolider », le sponsor part sur un autre sujet au trimestre suivant, et six mois plus tard il ne reste qu'un dépôt Git que personne n'ouvre.
J'ai vu ce scénario bien avant l'IA. Chez Amadeus, chez Air France-KLM, chez Enedis, ce sont les mêmes réunions, les mêmes questions, les mêmes silences — sur des sujets qui n'avaient rien à voir avec des modèles de langage. Ce qui a changé avec l'IA générative, c'est la vitesse à laquelle on arrive à la démo. Ce qui n'a pas changé du tout, c'est ce qu'il faut prouver pour aller plus loin.
Le chiffre, et ce qu'il ne dit pas
88 % des pilotes d'IA n'atteignent jamais la production. Le chiffre circule beaucoup en ce moment, il est solide, et les raisons invoquées par les équipes elles-mêmes sont toujours les mêmes trois : l'évaluation, la gouvernance, la fiabilité. Autrement dit : on ne sait pas mesurer si ça marche, on ne sait pas qui répond de quoi, et on ne sait pas ce qui se passe quand ça se trompe.
Deux précisions avant d'aller plus loin, parce que ce chiffre est souvent mal utilisé.
Un. Une partie de ces 88 % doit mourir. Beaucoup de pilotes sont lancés pour apprendre, ou pour répondre à une injonction interne — « faites quelque chose avec l'IA ». Un pilote qui prouve qu'un cas d'usage ne vaut pas le coup a fait son travail. Le gâchis, ce n'est pas qu'un pilote s'arrête ; c'est qu'un pilote qui marchait s'arrête pour des raisons qu'on aurait pu traiter dès le premier jour.
Deux. Le chiffre inverse est plus intéressant. Les organisations qui franchissent le cap mesurent des retours sur investissement qui ne ressemblent à rien d'autre dans un budget informatique. Ce n'est pas un argument pour se précipiter — c'est un argument pour ne pas laisser mourir les 12 % qui le méritent.
La vraie question n'est donc pas « comment sauver tous les pilotes ». C'est : est-ce que le mien meurt parce qu'il ne valait rien, ou parce que personne n'a préparé son passage à l'échelle ?
Ce qui sépare une démo d'un système
Une démo convainc sur vingt cas choisis. La production affronte des milliers de cas réels, tous les jours, y compris les moches : le client qui répond en pièce jointe, le PDF scanné de travers, la facture en double, l'utilisateur qui pose une question hors sujet, le service qui tombe un vendredi à 18 h.
Entre les deux, il y a six chantiers. Aucun n'est glamour. Aucun n'apparaît dans un budget de POC. Et ce sont exactement les six sur lesquels le projet se fait recaler.
1. La gestion des erreurs
Question à poser tôt : que se passe-t-il quand l'agent se trompe ? Pas « s'il se trompe ». Quand.
Il faut une réponse écrite à trois sous-questions : comment on le détecte, qui est prévenu, qui corrige. Dans la plupart des pilotes que je regarde, la réponse est : personne ne le détecte, parce qu'il n'y a pas de différence visible entre une bonne réponse et une réponse fausse formulée avec assurance. C'est la propriété la plus dangereuse de ces systèmes : ils échouent en gardant le même ton.
2. La traçabilité
Savoir ce que l'agent a fait, sur quelles données, et pourquoi. Horodaté, consultable, sans avoir à appeler un développeur.
C'est le chantier qui débloque tous les autres. Une DSI n'autorise pas ce qu'elle ne peut pas observer, et un régulateur n'accepte pas ce qui ne peut pas être reconstitué. Chez nous, ça porte un nom — le journal de preuve — et c'est la première chose qu'on branche, avant même d'améliorer les performances du modèle.
3. La validation humaine
Aux bons endroits. Ni partout, ni nulle part.
Partout, c'est le piège du « on met un humain dans la boucle » qui rassure tout le monde en réunion et transforme l'automatisation en surcharge de travail : au bout de trois semaines, la personne valide en série sans lire. Nulle part, c'est le cauchemar de la conformité. Le travail consiste à identifier les deux ou trois points où une décision est coûteuse ou irréversible, et à mettre le contrôle là, uniquement là.
4. La sécurité des accès
L'agent touche vos vrais systèmes : ERP, CRM, messagerie, base clients. Avec quels droits, ouverts par qui, révocables comment ?
Beaucoup de pilotes tournent avec les identifiants personnels de celui qui l'a construit. Ça passe en pilote. Ça ne passe jamais une revue de sécurité — et c'est normal.
5. Le contrôle des coûts
Un agent sans garde-fou consomme sans limite. Une boucle mal fermée, un document trop long, un pic d'usage, et la facture du mois n'a plus rien à voir avec le business case.
Ce n'est pas seulement une question d'argent : c'est une question de crédibilité. Un projet dont personne ne sait prévoir le coût unitaire ne passe pas un arbitrage budgétaire, quelle que soit sa performance.
6. La documentation
Celle que la DSI, l'auditeur et — désormais — le régulateur demanderont. Écrite pour être lue par quelqu'un d'extérieur, pas pour remplir une étagère.
C'est le chantier le plus reporté et le plus coûteux à rattraper. Reconstituer a posteriori les choix d'architecture, les données utilisées et les raisons d'une décision prise huit mois plus tôt, c'est un travail d'archéologie. Fait au fil de l'eau, c'est une heure par semaine.
Le protocole des 12 %
Ce que je viens de décrire ressemble à une liste de courses. C'est en réalité toujours la même mécanique, dans le même ordre. Nous l'appliquons aux systèmes d'IA comme aux obligations réglementaires, parce que c'est le même muscle.
Inventaire — qu'est-ce qui existe vraiment ? Les systèmes en usage, les composants, les flux de données, les accès, les responsables. Cette étape surprend toujours : dans une organisation de taille moyenne, il y a systématiquement plus d'IA en service que ce que la DSI en connaît. Des équipes ont branché des outils, des prestataires en ont livré, un abonnement traîne quelque part. On ne gouverne pas ce qu'on n'a pas cartographié.
Processus — qui fait quoi, quand, avec quelle validation ? Gestion des erreurs, points de contrôle, escalade, astreinte. Avec une règle qui ne se négocie pas : un processus qui ne vit que dans un PDF est mort. Il faut qu'il s'exécute — alerte réelle, ticket réel, personne réelle au bout.
Documentation — que montrez-vous à un auditeur ? Le dossier technique, la justification des choix, la politique de mise à jour. Versionné, daté.
Preuve — le système peut-il démontrer lui-même qu'il fonctionne ? Journaux, traçabilité des décisions, alertes, rapport périodique. C'est ce qui transforme « faites-nous confiance » en « vérifiez vous-même ». La conformité déclarée s'use. La conformité démontrée tient.
L'ordre compte. On voit souvent des équipes commencer par la documentation, parce que c'est ce qu'on leur a demandé — et produire un beau dossier qui décrit un système dont personne n'a fait l'inventaire réel. Ça ne tient pas dix minutes devant quelqu'un qui pose les bonnes questions.
Le calendrier honnête
Un audit de ce type prend deux à trois semaines. Il ne produit pas une présentation : il produit l'état des lieux, la liste des écarts, et un plan chiffré. La mise en production qui suit prend typiquement six à dix semaines selon le périmètre.
Et il faut dire l'autre partie : parfois, l'audit conclut que le pilote ne mérite pas la production. Un cas d'usage trop étroit, une donnée d'entrée trop sale, un gain réel bien inférieur au coût d'exploitation. C'est une conclusion utile, et elle vaut mieux que six mois de plus.
Le vrai point de départ
Si vous avez un pilote qui attend, il y a une question à poser avant toutes les autres, et elle n'est pas technique :
qui, en interne, portera ce système une fois qu'il tournera ?
Pas le sponsor. Pas le prestataire. La personne qui recevra l'alerte à 18 h un vendredi. Si ce nom n'existe pas, le projet mourra en production plutôt qu'avant — c'est la seule différence.
Les six chantiers se traitent. Les quatre étapes se suivent. Mais un système sans propriétaire meurt aussi, et aucun protocole ne répare ça.
À lire aussi — AI Act & CRA : ce qui est dû en 2026, ce qui est reporté en 2027 : le calendrier réglementaire que ce même protocole sert à tenir.
Keteris fait passer les pilotes d'IA en production : audit d'homologation, construction, exploitation. Nous appliquons cette méthode à nos propres produits — Le Reglo, plateforme de veille réglementaire, tourne en production depuis 2024.
Un pilote qui attend ? Réservez un cadrage de 30 minutes — réponse sous 24 h ouvrées, avis franc inclus.