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
Votre parcours
Outils de lecture
Notice de publication
Auteur
Thierry Gilgen
Édition
1
Publié
2026-07-15
Assistance IA
Non renseigné
Relecture éditoriale
Non renseigné
Répertoire structuré des sources
Aucune source structurée enregistrée. Les citations dans le texte sont distinctes.
Modification de l’édition
Baseline recorded from existing publication
SHA-256
81b2ae26ef288ba67747c2fb5c4156912790b5c8adb4dcb2f55e8a7447d4536e

Une empreinte identifie le texte et les métadonnées enregistrés. Elle ne certifie ni la véracité d’une affirmation ni le contenu des liens externes.

Thierry Gilgen. Pourquoi les projets d’IA échouent. Édition 1. 2026-07-15. https://www.thierry-gilgen-ict.ch/fr/field-notes/why-ai-projects-fail

Historique des éditions

Thierry Gilgen. Pourquoi les projets d’IA échouent. Édition 1. 2026-07-15. https://www.thierry-gilgen-ict.ch/fr/field-notes/why-ai-projects-fail

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.

Pour les prochaines lectures

Recevez la newsletter de Thierry sur Substack, ou suivez les nouveaux volumes de la Bibliothèque dans votre lecteur de flux.

Laisser une note en marge

Votre contribution est conservée en privé jusqu’à son examen ou sa suppression. Seule une note éditée et acceptée peut être publiée. N’incluez pas d’informations confidentielles. L’attribution est facultative.