Les projets IA qui échouent en PME ne butent presque jamais sur un problème de modèle. Ils butent sur des décisions prises avant la première ligne de code, ou sur des décisions qui n'ont pas été prises du tout. Voici les six que je rencontre le plus souvent, avec le signal qui permet de les repérer avant qu'il soit trop tard.
Les erreurs de départ
1. Commencer par l'outil
Quelqu'un a vu une démonstration, a été convaincu, et cherche maintenant où l'appliquer dans l'entreprise. L'ordre est inversé : on part de la solution pour trouver un problème.
Ça donne des projets sans propriétaire naturel, parce que personne n'avait demandé ça. L'outil est installé, quelques personnes l'essaient par curiosité, et l'usage retombe en trois semaines.
Signal d'alerte : le nom d'un produit apparaît dans la conversation avant qu'on ait décrit le problème.
Le correctif tient en une contrainte : interdire les noms d'outils pendant la première réunion de cadrage. Formuler le problème, les volumes, le gain visé. L'outil vient après, et il vient souvent tout seul.
2. Viser trop gros
L'ambition affichée est de « transformer la relation client » ou de « refondre le pilotage ». En PME, ces projets s'étalent sur des mois, mobilisent des gens qui ont déjà un métier à plein temps, et le premier résultat visible arrive trop tard pour maintenir l'attention.
Un projet IA en PME doit produire un effet perceptible en quelques semaines. Pas parce que la patience manque, mais parce que la crédibilité du sujet dans l'entreprise se joue sur le premier chantier. S'il n'aboutit pas, il n'y aura pas de deuxième.
Signal d'alerte : le périmètre annoncé concerne plus de deux équipes différentes.
Les erreurs de pilotage
3. Aucun critère d'évaluation
On lance, ça tourne, et trois mois plus tard la question « est-ce que ça marche ? » n'a pas de réponse commune. Chacun a son impression. Celui qui a porté le projet trouve que oui, ceux qui devaient l'utiliser trouvent que non, et le débat est sans issue parce qu'il n'y a rien à regarder.
Le critère se définit avant, avec le métier, sur des cas réels. Il n'a pas besoin d'être sophistiqué : sur vingt dossiers traités, combien de sorties sont utilisables sans reprise ? Un nombre, mesuré deux fois — avant et après.
Signal d'alerte : personne ne sait dire ce qui déclencherait l'arrêt du projet.
4. Pas de propriétaire côté métier
Le projet est porté par la direction ou par un prestataire, et pas par quelqu'un dont c'est le quotidien. Résultat : les décisions de détail — que faire des cas particuliers, où placer le curseur de qualité, quand escalader — sont prises par des gens qui ne les vivent pas.
Le propriétaire doit avoir un intérêt direct à ce que ça marche, du temps prévu dans son planning, et l'autorité pour arbitrer. C'est le point le plus corrélé à la survie du projet à un an, davantage que la qualité de la solution technique.
Signal d'alerte : à la question « qui possède ce sujet ? », on te répond un service, pas un prénom.
Les erreurs d'atterrissage
5. Découvrir tard que les données sont inaccessibles
On a validé le besoin, choisi l'approche, planifié les étapes. Puis on demande l'export, et là : l'historique est réparti dans des boîtes mail individuelles, le logiciel métier n'a pas d'API, le champ censé porter l'information est rempli en texte libre par sept personnes avec sept conventions.
Cette découverte, faite en semaine six, coûte le projet. Faite en semaine un, elle coûte une réunion et fait émerger un chantier préalable utile — centraliser, normaliser, décider qui saisit quoi.
Le test est simple et il ne se délègue pas : demander le fichier, réellement, et l'ouvrir. Tant que personne ne l'a ouvert, la donnée est une hypothèse.
Signal d'alerte : on te répond « on doit pouvoir l'exporter » plutôt que « voilà le fichier ».
6. Aucune formation prévue
Le budget couvre la conception et la construction. Rien pour l'accompagnement des utilisateurs. On mise sur le fait que l'outil sera intuitif.
Il ne l'est jamais complètement, et surtout ce n'est pas le sujet. Ce que les gens doivent apprendre, ce n'est pas où cliquer : c'est quand faire confiance à la sortie et quand ne pas y faire confiance. Ce jugement-là ne s'acquiert pas seul. Sans lui, deux comportements apparaissent — la confiance aveugle, qui laisse passer des erreurs, ou le rejet complet, qui fait retomber l'usage à zéro.
Prévois du temps d'accompagnement dans le budget initial, et pas seulement une session de lancement. Quelques points courts à trois semaines, puis à deux mois, changent l'adoption.
Signal d'alerte : la ligne « formation » n'existe pas dans le chiffrage, ou elle représente moins d'un dixième du total.
Ce qu'elles ont en commun
Aucune de ces six erreurs ne relève de la technique. Elles relèvent toutes du cadrage : définir le problème, mesurer, nommer un responsable, vérifier la matière, prévoir l'appropriation. C'est du travail de product management appliqué à un autre objet, rien de plus mystérieux.
Le test des six questions
Avant ton prochain lancement, réponds à ceci, par écrit, en une page : quel problème, quel gain mesuré, quel critère de succès, quel propriétaire, quelles données déjà entre nos mains, quel budget d'accompagnement. Si une réponse manque, tu sais où se trouve le risque — et tu le sais pendant qu'il est encore gratuit de le traiter.