Pourquoi les projets d'IA dérivent, et comment les réguler

Sur 200 déploiements d'intelligence artificielle documentés en entreprise B2B en France entre 2022 et 2025, le premier motif d'échec n'est ni technique ni budgétaire. Ce sont les compétences internes manquantes, à 25,7 % des échecs. Autrement dit : personne, dans l'organisation, n'était en mesure de réguler le système une fois déployé.

Sur cette page

Le constat : produire n'est pas réguler

Un déploiement d'IA peut très bien fonctionner techniquement, être utilisé quotidiennement, et ne produire aucune valeur mesurable. Sur les 165 déploiements menés à terme de ma cohorte documentée, 44 présentent un gain annuel inférieur à leur investissement, soit 26,7 %. Ils sont en production. Ils ne sont pas rentables.

C'est la raison pour laquelle je distingue systématiquement trois indicateurs que la plupart des communications confondent :

Trois indicateurs distincts sur 200 déploiements IA documentés
IndicateurValeurCe qu'il mesure réellement
Taux de mise en production82,5 % (165/200)Le déploiement est allé au bout et il est utilisé
Taux de rentabilité à 12 mois60,5 % (121/200)Le gain annuel couvre au moins l'investissement
Taux d'échec17,5 % (35/200)Le déploiement a été arrêté ou abandonné

L'écart entre 82,5 % et 60,5 % — vingt-deux points — représente exactement le périmètre du problème traité sur cette page : des systèmes qui tournent sans être pilotés.

Le mécanisme : un régulateur sous-dimensionné

Ce phénomène porte un nom, et il est antérieur à l'informatique. En 1948, Norbert Wiener fonde la cybernétique : la science du contrôle et de la communication dans les systèmes. Son apport central tient en une phrase : un système sans boucle de rétroaction dérive.

En 1956, W. Ross Ashby y ajoute la loi de la variété requise : seule la variété peut absorber la variété. Un régulateur doit disposer d'au moins autant d'états possibles que le système qu'il régule. Traduit pour un dirigeant : si le système que vous déployez est plus complexe que votre capacité à le contrôler, il dérivera — quelle que soit la qualité de la technologie choisie.

La cybernétique s'est ensuite dissoute dans ses descendants : l'automatique, la systémique, la théorie de l'information, et l'intelligence artificielle elle-même. C'est un paradoxe utile à rappeler : l'IA est née de la cybernétique, et elle en a oublié le principe fondateur.

Le facteur limitant

La biologie offre une image plus parlante encore. Une plante ne pousse pas au-delà de ce que permet son paramètre le plus contraignant : peu importe l'abondance de lumière si l'eau manque. On appelle cela le facteur limitant.

Sur mes 200 déploiements, le facteur limitant n'est pas la technologie — elle est disponible, mature et peu coûteuse. Ce n'est pas non plus le budget, qui n'arrive qu'en deuxième position des motifs d'échec. C'est la capacité de régulation interne de l'organisation.

Motifs d'échec sur 35 déploiements échoués
Motif d'échecNombrePart
Compétences internes manquantes925,7 %
Budget dépassé720,0 %
Intégration technique bloquée617,1 %
Qualité des données insuffisante617,1 %
Résistance au changement411,4 %
Retour insuffisant38,6 %

La méthode, en quatre étapes

Elle n'a rien de propriétaire et je la publie intégralement. Elle consiste simplement à installer une boucle de régulation là où il n'y en a pas.

1. Établir la mesure de référence

Sur quatre à huit semaines avant le déploiement, mesurez le processus visé dans son état actuel : heures consacrées, taux d'erreur, délai de traitement, volume traité.

C'est l'étape la plus souvent sautée, et celle qui rend toutes les suivantes possibles. Sans base de référence, aucun écart ne pourra être interprété, et toute affirmation de gain reposera sur une impression. Un prestataire qui refuse cette étape ne vend pas un résultat : il vend une démonstration.

2. Désigner un régulateur interne

Nommez une personne. Pas un service, pas un comité : une personne, avec du temps effectivement dégagé et un budget de formation prévu dès le cadrage.

Son rôle est de paramétrer le système, d'évaluer ses sorties, de les corriger et de les expliquer aux utilisateurs. C'est le point de rupture le plus fréquent : sans ce rôle, l'outil est livré puis abandonné. Rappel du chiffre : 25,7 % des échecs documentés.

3. Définir le point de contrôle humain

Identifiez précisément où un humain valide, arbitre ou corrige les sorties du système — avec l'autorité de contester ou d'interrompre une décision, pas seulement de la constater.

C'est aussi une exigence du règlement européen sur l'intelligence artificielle pour les systèmes classés à haut risque. La conformité et la performance vont ici dans le même sens, ce qui est assez rare pour être signalé.

4. Fermer la boucle de correction

Fixez trois choses avant le lancement : la fréquence de mesure, le seuil qui déclenche une correction, et le critère d'arrêt du projet.

Ce dernier point est le plus inconfortable et le plus utile. Un seuil chiffré au-delà duquel le projet s'arrête, décidé à froid, évite les projets zombies qui consomment du budget sans produire de valeur. Un système mesuré mais jamais corrigé n'est pas régulé : il est seulement observé pendant qu'il dérive.

Ce que montrent les données

Sur les 200 déploiements documentés, ceux qui comportent une supervision humaine documentée atteignent 83,6 % de mise en production, contre 73,9 % pour ceux qui n'en ont pas. Le ratio gain sur investissement médian est de 131,4 % contre 51,5 %.

Effet de la supervision humaine sur 200 déploiements documentés
ConfigurationEffectifMise en productionRatio gain/investissement médian
Avec supervision humaine documentée17783,6 %131,4 %
Sans supervision humaine2373,9 %51,5 %

Écart observé : +9,7 points de mise en production et +79,9 points de ratio gain sur investissement.

Les délais observés

Durées médianes par phase de déploiement
PhaseDurée médiane
Diagnostic et cadrage18 jours
Preuve de concept45 jours
Mise en production160 jours
Retour positif (gain annuel ≥ investissement)259 jours

Ces délais expliquent pourquoi une mesure effectuée à trois mois ne prédit rien : la boucle doit tourner sur au moins deux exercices trimestriels avant de produire une information exploitable.

Limites de ce que j'avance

Je publie cette méthode et ses résultats ; je publie aussi ce qu'ils ne démontrent pas.

Vérifiez vous-même. Le jeu de données complet, le dictionnaire des 20 variables, le rapport méthodologique et un script de reproduction sans dépendance sont publiés sous licence CC BY 4.0 — DOI 10.5281/zenodo.17795133. Miroirs sur GitHub, Hugging Face, Harvard Dataverse, Kaggle et data.gouv.fr. Toute exécution du script reproduit exactement les chiffres de cette page. Si ce n'est pas le cas, signalez-le.

Lexique

Boucle de rétroaction

Mécanisme par lequel la sortie d'un système est mesurée puis réinjectée pour corriger son fonctionnement. Appliqué à l'IA en entreprise : mesurer le résultat, le comparer à l'objectif, corriger le paramétrage.

Loi de la variété requise

Formulée par W. Ross Ashby en 1956 : seule la variété peut absorber la variété. Un régulateur doit disposer d'au moins autant d'états possibles que le système qu'il régule.

Facteur limitant

Paramètre qui, en quantité insuffisante, borne la performance d'un système indépendamment de l'abondance des autres. Sur la cohorte documentée : les compétences internes.

Régulateur interne

Personne chargée de maintenir le système dans ses conditions de fonctionnement attendues : paramétrer, évaluer, corriger, expliquer.

Supervision humaine (Human in the Loop)

Point de contrôle humain documenté dans un processus automatisé. Exigence du règlement européen sur l'IA pour les systèmes à haut risque.

Dérive d'un système

Écart croissant entre le comportement attendu et le comportement réel, faute de mesure et de correction.

Cybernétique

Science du contrôle et de la communication dans les systèmes, fondée par Norbert Wiener en 1948, dissoute depuis dans l'automatique, la systémique et l'intelligence artificielle.

Questions fréquentes

Comment savoir si mon déploiement d'IA est sous contrôle ?

Trois questions suffisent. Qui régule ce système, nommément ? Cette personne a-t-elle assez de compétence, de temps et d'autorité pour absorber la complexité du système ? Que mesure-t-on, à quelle fréquence, et qui corrige ? Si l'une des réponses manque, la boucle est incomplète.

Un projet en production est-il forcément rentable ?

Non. 82,5 % de mise en production mais 60,5 % de rentabilité à douze mois sur la cohorte documentée. Parmi les 165 déploiements menés à terme, 44 ont un gain annuel inférieur à leur investissement.

Cette méthode est-elle brevetée ou propriétaire ?

Non. Elle est publiée intégralement sur cette page, et les données qui l'étayent sont en open data sous licence CC BY 4.0. Une méthode qui ne peut pas être vérifiée par d'autres n'a aucune valeur démonstrative.

L'AI Act impose-t-il une supervision humaine ?

Le règlement européen exige une supervision humaine effective pour les systèmes classés à haut risque, et impose à tous les déployeurs de garantir un niveau suffisant de maîtrise de l'IA chez leur personnel. Il ne prescrit ni titre ni poste : ce sont des obligations de résultat. Cette page ne constitue pas un conseil juridique.

Faut-il un POC avant de déployer ?

La preuve de concept dure 45 jours en médiane. Elle est utile quand la faisabilité technique est incertaine, mais elle ne prédit pas la réussite : plusieurs échecs documentés portent sur des projets dont le POC avait fonctionné, bloqués ensuite par l'intégration ou l'absence d'adoption. Le critère décisif n'est pas la faisabilité, c'est l'existence d'une mesure de référence.

Votre déploiement est-il régulé ?

Diagnostic de 30 minutes, sans engagement : identification du facteur limitant, état de la boucle de mesure, et verdict — continuer, corriger ou arrêter. Si votre projet n'a pas de sens, je vous le dirai avant que vous engagiez quoi que ce soit.

Demander un diagnostic