Pourquoi la plupart des projets IA échouent avant le premier modèle
Une démonstration impressionne, un pilote fonctionne, et six mois plus tard plus personne n'ouvre l'outil. Ce scénario est si répandu qu'on finit par croire que l'IA ne tient pas ses promesses. En réalité, l'échec se produit presque toujours en amont du modèle, sur des sujets peu spectaculaires que personne n'a voulu prendre en charge.
Le premier point de rupture : des données que personne n'a reprises
Dans une PME normale, les contacts vivent dans le CRM, dans un tableur, dans une boîte mail et dans la tête de deux personnes. Les mêmes clients y figurent trois fois, avec trois orthographes. Les documents sont nommés selon quatre conventions successives. Une IA branchée là-dessus produit des réponses parfaitement formulées et parfaitement fausses, ce qui est pire qu'une absence de réponse.
Le symptôme qui ne trompe pas
Si personne ne sait dire combien de clients actifs a l'entreprise sans ouvrir trois outils, le problème n'est pas l'IA.
Le deuxième : des intégrations qui n'existent pas
Le logiciel métier d'un couvreur, d'une fiduciaire ou d'un syndic n'a souvent aucune interface programmable. Beaucoup de projets s'arrêtent là, avec la conclusion que l'entreprise n'est pas prête. C'est une inversion : construire le pont fait partie du travail, ce n'est pas un préalable à la charge du client.
Le troisième : une interface de plus
Un outil qui demande à une équipe d'ouvrir une application supplémentaire sera abandonné, quelle que soit sa qualité. Les équipes travaillent dans leur messagerie, dans WhatsApp, dans Slack ou dans Teams. Un dispositif qui vit ailleurs vit trois semaines.
La règle est mécanique : ce qui demande un changement d'habitude sans bénéfice immédiat n'est pas adopté.
Le quatrième : personne ne tient le système
Un système d'agents n'est pas livré, il est tenu. Les modèles évoluent, les API changent, les processus bougent, les correctifs de sécurité tombent. Un dispositif laissé sans maintenance devient une surface d'attaque en quelques mois, et une source d'erreurs bien avant.
Ce qu'il faut monter avant de parler de modèle
- 1Reprendre les données : doublons fusionnés, champs normalisés, historique repris, documents indexés.
- 2Construire les connexions, y compris là où aucune API n'existe.
- 3Poser le modèle de permissions : quel agent voit quoi, ce qui part seul, ce qui attend un accord.
- 4Choisir l'hébergement selon la sensibilité réelle des données.
- 5Installer la journalisation, sans laquelle aucune action n'est auditable.
- 6Prévoir le maintien dans la durée, dès le premier jour.
Cette liste n'a rien de spectaculaire, et c'est précisément pourquoi elle est sautée. Elle représente pourtant l'essentiel du travail et la totalité de la différence entre un pilote qui meurt et un système qui tourne encore deux ans plus tard.
Demandez à votre prestataire ce qu'il fait de vos données existantes, comment il compte se brancher sur votre logiciel métier, qui aura accès à quoi, et ce qui se passe si vous arrêtez. Si les quatre réponses sont vagues, le projet échouera avant le premier modèle, quel que soit le modèle.
Conclusion
À retenir
L'IA n'est presque jamais le point faible d'un projet IA. Les données, les connexions, les permissions et le maintien le sont. Une entreprise qui traite ces quatre sujets réussit avec des modèles ordinaires ; une entreprise qui les ignore échoue avec les meilleurs.
Comment le vérifier avant de s'engager