Un prototype qui fonctionne est une mauvaise nouvelle déguisée en bonne nouvelle. Il crée un enthousiasme immédiat, souvent en quelques jours, et donne le sentiment que le plus dur est fait. En réalité, la démonstration ne prouve qu’une seule chose : le problème est techniquement soluble. C’est utile, mais c’est la partie la plus facile.
La suite est nettement moins spectaculaire. Il faut brancher l’outil sur des données réelles, décider qui valide quoi, absorber les cas particuliers, tenir la charge, et surtout modifier la façon de travailler de personnes qui n’ont rien demandé. C’est là que la majorité des projets s’arrêtent, généralement sans décision explicite. Ils ne sont pas abandonnés, ils s’endorment.
Voici les causes récurrentes, dans l’ordre où elles apparaissent.
Les huit causes récurrentes
1. Les données du prototype ne ressemblent pas aux données réelles
C’est la cause numéro un, et de loin. Le prototype tourne sur quinze dossiers choisis, bien remplis, récents et cohérents. La production, ce sont quatre mille dossiers dont une partie date de 2016, avec des champs vides, des conventions de nommage qui ont changé trois fois, des doublons et des exceptions que personne n’a documentées.
Le résultat est brutal : une solution qui donnait 95 % de réponses correctes en démonstration tombe à 60 % sur le flux réel. Et 60 %, dans un processus métier, ne vaut souvent rien du tout, parce qu’il faut relire les 100 % pour trouver les 40 % à corriger.
2. Personne n’a défini ce que signifie réussir
Beaucoup de prototypes sont jugés à l’impression qu’ils produisent en réunion. Personne n’a écrit avant de commencer : quel taux d’erreur est acceptable, quel délai, quel coût par dossier, et par rapport à quelle situation actuelle.
Sans référence de départ, il devient impossible de trancher. Le débat se déplace vers les goûts et les inquiétudes, et le projet reste en évaluation permanente. On demande une nouvelle démonstration, puis une autre.
3. Les erreurs n’ont pas de traitement prévu
Une IA se trompe. La question n’est pas de savoir si elle se trompe, mais ce qui se passe quand elle se trompe.
Les projets qui passent en production ont répondu à trois questions : comment détecte-t-on une erreur, qui la corrige, et qui en porte la responsabilité vis-à-vis du client. Ceux qui n’y répondent pas restent bloqués sur une exigence implicite de perfection que personne n’appliquerait à un humain.
La bonne conception consiste souvent à distinguer deux flux : les cas où le système est sûr de lui, traités automatiquement, et les cas incertains, envoyés à un humain. Un outil qui traite 70 % des dossiers seul et signale honnêtement les 30 % restants a bien plus de valeur qu’un outil qui traite tout avec 90 % de fiabilité et ne dit jamais quand il doute.
4. Le coût réel n’a pas été calculé
Le prototype coûte quelques jours de travail. La production coûte l’intégration au système d’information, l’authentification, la gestion des accès, la journalisation, la supervision, un plan de reprise, la formation, la documentation et la maintenance.
Il y a aussi un coût que les prototypes masquent : le coût unitaire. En démonstration, on traite dix requêtes. En production, dix mille par mois. Les projets qui n’ont pas fait ce calcul découvrent tard que l’économie de temps est réelle mais que la facture d’usage la mange en partie.
5. Aucun responsable métier ne l’attend
Un prototype porté par la DSI, l’innovation ou un prestataire extérieur n’a pas de destinataire. Personne, côté métier, n’attend qu’il arrive.
Or la mise en production est avant tout un changement de pratiques. Elle demande à des gens de modifier leur façon de travailler, d’accepter une période de baisse de performance, et de faire remonter les défauts au lieu de contourner l’outil en silence. Cela ne s’obtient qu’avec un responsable métier qui a un intérêt direct au résultat.
6. Le processus, lui, ne change pas
Un prototype ajouté à un processus inchangé produit un gain qui disparaît. Les vingt minutes économisées à la rédaction sont reperdues dans une validation qui n’a pas bougé, un circuit de signature identique, une ressaisie dans un autre outil.
Les projets qui tiennent sont ceux où l’on a accepté de supprimer des étapes, pas seulement d’en accélérer une. C’est un travail d’organisation, souvent politique, et c’est pour cette raison qu’il est fréquemment évité.
7. La sécurité arrive trop tard
Sécurité, protection des données, secret professionnel, contraintes sectorielles : ces sujets sont traités en dernier parce qu’ils sont perçus comme des freins. Ils deviennent alors de véritables freins, puisqu’ils remettent en cause l’architecture au moment du déploiement.
Une conversation de trente minutes en début de projet sur les données mobilisées, leur localisation et leur usage évite quasi systématiquement un blocage tardif.
8. Le prototype est pris pour le produit final
Un prototype est construit vite, sans tests, sans gestion des erreurs, souvent par une seule personne, parfois dans un outil qui ne tiendra pas la charge. C’est normal et c’est même souhaitable.
Le problème survient quand on tente de le mettre en production tel quel, parce qu’il « marche déjà ». On passe alors des mois à consolider une base fragile, avec un résultat inférieur à ce qu’aurait donné une réécriture.
Cinq questions avant de commencer
À poser avant d’écrire la première ligne. Trois « non » suffisent à reporter le projet.
- Quel utilisateur nommé attend ce résultat, et que gagne-t-il personnellement ?
- Quelle est la mesure actuelle du processus : temps, délai, erreurs et coût ?
- À partir de quel niveau de fiabilité décide-t-on de déployer, et que fait-on des erreurs ?
- Les données nécessaires sont-elles accessibles, complètes et autorisées, dès aujourd’hui ?
- Quelle étape du processus disparaîtra si cela fonctionne ?
Décider fait partie du prototype
Tous les prototypes ne doivent pas passer en production, et c’est sain. Un prototype abandonné après trois semaines parce qu’il a démontré que les données n’étaient pas exploitables est un succès : il a coûté peu et évité un chantier de six mois.
Ce qui coûte cher, ce sont les prototypes maintenus en vie sans décision, présentés une fois par trimestre, jamais déployés et jamais enterrés. Ils occupent du temps, entretiennent une illusion d’avancement et découragent les équipes.
Fixez une date de décision au moment du lancement. À cette date, le projet passe en production, il est réorienté, ou il est arrêté et documenté. Les trois issues sont acceptables. L’absence de choix ne l’est pas.