Pourquoi les projets IA s'arrêtent entre la démonstration et la production
Aucune de ces raisons n'est un problème de modèle. Toutes apparaissent au moment où l'on quitte les données de démonstration pour les vraies.
Dans cet article6 sections
- La démonstration est la partie facile
- Dix documents de démonstration ne disent rien de dix mille documents réels
- Travailler sur de vraies données, c'est travailler sur des données personnelles
- L'IA ne répare pas des données en désordre, elle les met en pleine lumière
- Le prix d'un projet IA, ce n'est pas ce qu'il coûte à construire
- Sans critère de réussite écrit avant, un projet ne peut ni réussir ni s'arrêter
La démonstration est la partie facile
Sur quelques cas bien choisis, presque tout marche, et tout le monde repart enthousiaste.
Le reste : les cas tordus, la charge réelle, les droits d'accès, les gens qui doivent changer leur façon de travailler : c'est là que ça coince, et là que les budgets s'arrêtent. Près de la moitié des preuves de concept n'arrivent jamais en service : la facture est réelle, le bénéfice ne l'est jamais devenu.
La parade tient dans une habitude de construction : tenir compte, dès le prototype, de ce que le passage en production exige. Les droits d'accès, les cas limites, le coût par utilisation, ce qu'il faudra surveiller et qui devra le faire.
Dix documents de démonstration ne disent rien de dix mille documents réels
Une démonstration se prépare avec ce qu'on a sous la main : une dizaine de PDF propres, de quelques pages, choisis parce qu'ils se lisent bien. En production, ce sont des décomptes de plusieurs centaines de pages, des scans de travers, des fichiers qui arrivent par lots chaque matin.
Ce changement d'échelle ne demande pas seulement plus de patience : il fait apparaître des contraintes que le prototype ne connaissait pas. La mémoire du serveur, le temps de traitement, les délais d'attente, le coût par page. Sur l'un de nos projets d'extraction, un seul document de près de 500 pages suffisait à bloquer la machine qui traitait sans effort les fichiers de test. Sur un autre, un document de 190 pages demandait plus de deux heures de traitement.
Prototyper simple reste la bonne approche : c'est le moyen le plus rapide de montrer ce qui est possible. Mais il faut obtenir très vite un échantillon de vraies données : les plus gros fichiers, les plus mal scannés, les plus anciens, et le volume d'un mois normal. C'est cet échantillon qui dit ce que la production va exiger, pas la démonstration.
Travailler sur de vraies données, c'est travailler sur des données personnelles
Dès qu'on quitte les données de démonstration, on manipule des noms, des adresses, des dossiers de clients ou de patients. Les envoyer tels quels à un modèle hébergé ailleurs, c'est les confier à un tiers, avec tout ce que la loi sur la protection des données exige alors.
La réponse la plus solide est d'anonymiser avant l'envoi : remplacer les noms et les identifiants par des marqueurs, laisser le modèle travailler sur le texte neutralisé, puis réinsérer les vraies valeurs au retour. Sur un projet médical, nous avons posé l'exigence avant de construire : aucun nom de patient ne doit passer. Le contrôle a porté sur plus de deux cents cas réels, tous détectés. Et si la détection échoue, l'outil s'arrête plutôt que d'envoyer le texte en clair.
Un prototype peut se passer de tout ça. Un système en production, jamais. Et les données réelles ont tendance à rester là où elles ont servi : dans un jeu de test, un dépôt de code, un compte de démonstration jamais supprimé. Elles se traitent avec les règles de la production dès le premier jour où elles entrent dans le projet.
L'IA ne répare pas des données en désordre, elle les met en pleine lumière
Le jour où on demande à un modèle d'apprendre de votre historique, on découvre les doublons, les champs remplis à moitié, les trois conventions de nommage qui coexistent depuis dix ans.
Ce n'est pas un problème technique : c'est la réalité de toutes les entreprises, et personne ne l'avait regardée en face parce que les humains compensaient sans le dire.
Un projet qui ne prévoit pas ce travail-là ne prévoit pas la moitié de son budget. D'où l'intérêt d'ouvrir les données avant de promettre un modèle : le volume réel, la qualité réelle, ce qui est exploitable et ce qui ne l'est pas. Cette étape dit souvent qu'il faut d'abord ranger, ou qu'un traitement plus simple suffirait.
Le prix d'un projet IA, ce n'est pas ce qu'il coûte à construire
Ce qui pèse, c'est ce qui vient après : le coût à chaque appel, la surveillance, les modèles qui changent sous vos pieds, les cas nouveaux qu'il faut traiter.
Beaucoup de projets sont validés sur un budget de développement puis abandonnés dix-huit mois plus tard sur un coût de fonctionnement que personne n'avait chiffré.
Un système qu'on n'a pas les moyens de faire tourner n'a jamais vraiment été livré. Ce coût-là s'estime avant la construction, pas après.
Sans critère de réussite écrit avant, un projet ne peut ni réussir ni s'arrêter
« Voir ce que l'IA peut faire pour nous » n'est pas un objectif : c'est une dépense sans ligne d'arrivée.
Faute de seuil défini au départ, personne ne peut dire si le résultat est bon, alors on relance un tour, puis un autre, jusqu'à ce que quelqu'un coupe le budget par lassitude. C'est la première cause d'abandon, loin devant les difficultés techniques.
Écrire ce seuil au début est inconfortable : un délai, un taux d'erreur, un volume traité, et ce qui déclenche l'arrêt. C'est beaucoup moins coûteux là qu'à la fin.
Un projet IA se juge mal sur sa démonstration et bien sur son coût de fonctionnement. Les points ci-dessus reviennent tous à la même question, posée avant de commencer : qu'est-ce qui, dans six mois, permettra de dire que ça valait la peine, ou qu'il faut s'arrêter ?
Ce sujet touche à notre expertise Projet IA sur mesure.
On commence par une discussion, pas par un devis.
Voir l'expertiseÀ lire ensuite
