Il existe un scénario que nous voyons se répéter dans presque toutes les PME que nous rencontrons. Un prototype est construit, souvent vite, souvent bien. La démonstration impressionne. La direction valide le principe. Puis plus rien. Six mois après, le prototype tourne encore sur le poste de la personne qui l'a construit, et le processus continue d'être exécuté à la main comme avant.
Ce n'est presque jamais un problème de technologie. Voici ce que c'est vraiment.
1. Le pilote a été construit sur des données trop propres
Un prototype se teste naturellement sur les cas les plus simples : les documents bien scannés, les commandes bien formulées, les dossiers complets. Ce sont ceux qu'on a sous la main, et ce sont ceux qui donnent une belle démonstration.
Le problème, c'est que dans la vraie vie ces cas représentent souvent 60 à 70 % du flux. Le reste, ce sont les scans de travers, les pièces jointes manquantes, les commandes qui référencent « comme d'habitude » sans donner de référence produit. Un système qui traite correctement 70 % des cas et échoue silencieusement sur les 30 % restants est inutilisable en production : il crée plus de travail de vérification qu'il n'en supprime.
Ce qu'il faut faire à la place : confronter le prototype à un échantillon représentatif dès la première semaine, y compris aux dossiers que tout le monde évite. Le taux de fiabilité annoncé doit être mesuré sur ce flux réel, pas sur une sélection.
2. Personne n'a défini ce qui se passe quand ça se trompe
C'est la question qui décide de la mise en production, et c'est celle qu'on repousse le plus volontiers. Que se passe-t-il quand l'extraction lit 1 200 au lieu de 12 000 ? Qui le voit ? Quand ?
Un système d'automatisation n'a pas besoin d'être parfait. Il a besoin d'être prévisible :
- les cas traités automatiquement, parce que la confiance est suffisante et l'enjeu limité ;
- les cas mis en attente de validation humaine, parce que le montant, le client ou l'écart le justifient ;
- les cas refusés et renvoyés au traitement manuel, sans tentative de deviner.
Tant que ces trois catégories ne sont pas écrites avec des seuils chiffrés, aucun responsable ne prendra la responsabilité d'ouvrir le système à toute l'équipe. Et il aura raison.
3. Le processus manuel a été supprimé trop tôt
Il y a une tentation, une fois l'automatisation en place, de couper l'ancien chemin pour forcer l'adoption. C'est une erreur qui coûte cher la première fois qu'un service tiers tombe en panne un jour de clôture.
Le traitement manuel doit rester possible et documenté, indéfiniment. Ce n'est pas un aveu de faiblesse : c'est ce qui permet à un dirigeant d'autoriser le déploiement sans mettre son activité en dépendance d'un système qu'il ne maîtrise pas.
4. Le projet reposait sur une seule personne
Dans une PME, le projet IA est souvent porté par la personne la plus curieuse de l'entreprise — parfois le dirigeant lui-même, parfois un responsable administratif motivé. C'est une excellente nouvelle pour le démarrage et un risque majeur pour la suite.
Si cette personne part, change de poste, ou se retrouve absorbée par une urgence commerciale pendant deux mois, le projet s'arrête. Il faut donc, dès le cadrage :
- désigner un référent et un suppléant ;
- documenter les règles métier ailleurs que dans la tête du référent ;
- former au moins deux personnes à la supervision quotidienne.
5. Le coût récurrent n'a jamais été chiffré
Un prototype qui traite trente documents par jour pendant un test coûte quelques euros. Le même système qui traite huit cents documents par jour toute l'année, ce n'est plus le même sujet.
Nous avons vu des projets s'arrêter au moment de la mise en production, non parce qu'ils ne fonctionnaient pas, mais parce que personne n'avait calculé la facture mensuelle à pleine charge. Ce calcul doit être fait au cadrage, avec une estimation haute, et présenté en même temps que le coût de développement.
Ce que ça change concrètement dans notre façon de travailler
Ces cinq points ont une conséquence directe : la phase la plus importante d'un projet d'automatisation n'est pas le développement, c'est le cadrage. C'est là qu'on écrit les seuils, les exceptions, les chemins de secours et le budget d'exécution.
C'est aussi pour cela que nous refusons de démarrer un développement sans une phase de diagnostic préalable. Un prototype construit sans comprendre le processus réel produit une démonstration convaincante et une impasse.
Trois questions à poser à n'importe quel prestataire
Si vous êtes en train de choisir un partenaire pour un projet d'IA, ces trois questions filtrent efficacement :
- Sur quelles données allez-vous mesurer la fiabilité ? Si la réponse n'inclut pas « les vôtres, y compris les cas difficiles », passez votre chemin.
- Que se passe-t-il quand le système n'est pas sûr de lui ? Il doit exister une réponse précise, pas « on ajustera ».
- Combien ça coûte par mois une fois en production, à plein volume ? Un ordre de grandeur suffit, mais il doit exister.
Aucune de ces questions ne porte sur la technologie employée. C'est normal : ce n'est presque jamais là que les projets échouent.
