Les 7 erreurs des déploiements IA, vues du terrain

Un échec de projet IA est rarement un échec technique. Les modèles fonctionnent. Ce qui échoue, c’est tout ce qu’il y a autour : le cadrage, l’exécution, la gouvernance. Dans les entreprises que nous auditons, les mêmes sept erreurs reviennent — avec une régularité qui finit par ressembler à une loi.

Aucune n’est exotique. C’est précisément ce qui les rend dangereuses : elles paraissent toutes raisonnables au moment où on les commet.

Avant le lancement : trois erreurs de cadrage

Erreur n° 1 : pas de sponsor. Le projet est porté par un enthousiaste — un développeur, un responsable marketing — sans mandat de la direction. Tant qu’il s’agit d’expérimenter, tout va bien. Dès qu’il faut arbitrer un budget, ouvrir un accès ou imposer un changement de process, le projet s’arrête net. Un déploiement IA touche à l’organisation ; sans quelqu’un qui a le pouvoir de trancher, il reste un hobby.

Erreur n° 2 : pas de mesure. Personne n’a défini ce que « ça marche » veut dire. Six mois plus tard, la question « qu’est-ce que ça nous rapporte ? » tombe en comité de direction, et personne n’a de réponse. Un projet qui ne peut pas prouver sa valeur est un projet qu’on coupe à la première tension budgétaire.

Erreur n° 3 : acheter des licences en croyant acheter un déploiement. La licence donne accès au moteur. Elle ne fournit ni les contextes métier, ni les cas d’usage, ni la conduite du changement. Des licences distribuées sans rien autour produisent un résultat prévisible : 10 % d’utilisateurs enthousiastes, 90 % qui ont essayé deux fois puis sont retournés à leurs habitudes.

Pendant : deux erreurs d’exécution

Erreur n° 4 : la formation générique. Une demi-journée de « sensibilisation à l’IA », les mêmes slides pour la comptabilité et pour le développement. Chacun repart avec des généralités et aucun cas d’usage applicable à son poste dès le lendemain. La formation qui fonctionne est l’inverse : par métier, sur les vrais dossiers de l’équipe, avec des livrables à la fin.

Erreur n° 5 : le pilote éternel. Le POC a marché, tout le monde est content — et il tourne encore, dix-huit mois plus tard, avec les trois mêmes utilisateurs. Un pilote sans date de fin et sans critères de généralisation n’est pas une étape : c’est une destination. Le passage à l’échelle doit être décidé avant le pilote, pas après.

Autour : deux erreurs de gouvernance

Erreur n° 6 : la DSI contournée. Les équipes s’équipent en douce, les données partent dans des outils non validés, et le jour où la DSI découvre l’ampleur du shadow IT, elle bloque tout — à juste titre. Le réflexe inverse est le bon : associer la DSI dès le départ, définir avec elle ce que l’IA peut lire et ne peut pas lire. C’est elle qui transforme un projet toléré en projet durable.

Erreur n° 7 : personne pour maintenir le système. Le prestataire est parti, ou le champion interne a changé de poste, et plus personne ne met à jour les contextes ni les compétences packagées. Un système IA sans propriétaire se dégrade comme un jardin sans jardinier — lentement, puis brutalement.

Le point commun des sept

Aucune de ces erreurs ne concerne le modèle. Toutes concernent l’architecture autour : qui décide, qui mesure, qui forme, qui sécurise, qui maintient. C’est exactement le rôle de ce que nous appelons le Harness — la couche d’orchestration entre Claude et vos process : contextes métier, skills par département, garde-fous, pilotage.

La bonne nouvelle : ces erreurs se corrigent dans l’ordre. Un sponsor, des métriques définies avant le lancement, une formation par métier, un pilote borné, une DSI associée, un propriétaire nommé. C’est la colonne vertébrale de notre Programme Autonomie Claude — trois semaines pour poser cette architecture, avec une équipe autonome à la fin.

• Pas de sponsor : le projet meurt au premier arbitrage.
• Pas de mesure : impossible de prouver la valeur, donc impossible de survivre à un budget.
• Licences sans déploiement : 90 % des utilisateurs abandonnent en quelques semaines.
• Formation générique : aucune application concrète le lendemain.
• Pilote éternel : le POC devient une destination au lieu d’une étape.
• DSI contournée : le shadow IT finit toujours par un blocage général.
• Pas de propriétaire : le système se dégrade dès le départ du prestataire.