Aller au contenu principal

Pourquoi les projets d’IA échouent

Rarement le modèle. Presque toujours l’absence de maître d’œuvre.

Night office meeting around a conference table beside a whiteboard of abstract process boxes

On s’en prend d’abord au modèle. Un projet d’intelligence artificielle s’effondre, et voilà le coupable tout trouvé.

Il a inventé. Il a mal lu la consigne. Il a coûté trop cher. Il n’était pas assez juste.

Il arrive que ce soit vrai. Un modèle a des limites ; on a tort de les négliger.

Pourtant, bien des projets meurent avant même que la qualité du modèle puisse décider de quoi que ce soit. Ils meurent faute de maître : personne n’assume vraiment le système en marche.

Chacun tient un morceau. L’innovation garde l’expérience. L’informatique tient les machines. Le juridique tient la règle. La sécurité tient les interdits. Une direction métier tient le budget. Un cabinet tient le discours. Un éditeur tient le modèle. Le résultat, lui — ce qui se passe réellement, au quotidien, une fois le système en service — n’appartient à personne.

Tant que l’on reste en pilote, on s’en accommode. Une petite équipe rattrape à la main les mauvaises données, explique les sorties bizarres, retouche les consignes, accompagne quelques utilisateurs choisis. Rien n’éclate encore.

Puis vient la production.

Il faut alors savoir qui veille à la qualité, qui tranche quand le système se trompe, qui autorise une modification, qui réagit si le fournisseur change son modèle, qui porte le flux de données, qui sait ce que coûte vraiment une tâche métier menée à bien, qui a le pouvoir d’arrêter la machine, et qui rend des comptes lorsque les gens se mettent à lui faire trop confiance.

Sans réponses nettes, on n’a pas un système. On a un tas de devoirs laissés en suspens, collés par l’enthousiasme.

L’IA verse de l’incertain dans des organisations qui, d’habitude, s’efforcent de tout rendre prévisible. Cela ne la rend pas inutilisable. Cela rend plus urgente encore la maîtrise opérationnelle.

Un produit d’IA digne de ce nom ne se réduit pas à un modèle et à un écran. Il lui faut des droits de décision clairs, des critères pour juger, des voies d’escalade, de quoi auditer, de quoi surveiller, des garde-fous sur les coûts, un périmètre de sécurité, des retours d’usage — et surtout quelqu’un qui porte à la fois la charge et le pouvoir.

Il lui faut aussi une sortie.

Si le fournisseur disparaît ou se dégrade, peut-on le remplacer ? Les données reviennent-elles ? Les résultats importants se reconstruisent-ils ? L’activité tient-elle encore si le modèle préféré n’est plus là, plus abordable, ou plus adapté ?

Ce n’est pas de la gouvernance pour la gouvernance. C’est le produit.

Un bon modèle peut servir un système dont quelqu’un a vraiment la charge. Il ne rattrape pas une organisation qui a délégué sa responsabilité sans même s’en apercevoir.

Les projets d’IA n’échouent pas, le plus souvent, parce que le modèle manquait d’intelligence. Ils échouent parce que l’organisation manquait d’un responsable.