Un proof of concept démontre qu'une idée peut fonctionner dans des conditions favorables. Un système de production doit fonctionner chaque jour, pour de vrais utilisateurs, sur des données réelles, au côté de systèmes qui n'ont jamais été conçus pour l'accueillir. Beaucoup d'organisations ne mesurent l'écart qu'après une démonstration réussie, suivie de plusieurs mois de silence. Cet article explique pourquoi cela se produit et comment organiser un projet par étapes pour que la démo dispose d'un chemin réaliste vers la production.

Pourquoi les proof of concept s'arrêtent

La plupart des proof of concept qui s'arrêtent partagent un petit nombre de causes. Aucune n'est technique au sens strict, et toutes peuvent être repérées dans les premières semaines du projet.

  • Pas de responsable métier. Le travail est porté par une équipe innovation ou informatique, et personne dans le service opérationnel n'a accepté de modifier un processus à cause de lui.
  • Accès aux données supposé. La démo s'appuyait sur un export préparé à la main, alors que les données réelles se trouvent dans des systèmes qui ont leurs propres responsables, leurs droits d'accès et leurs problèmes de qualité.
  • Aucune intégration avec les systèmes existants. Le prototype fonctionne seul, de sorte que le coût de son raccordement à l'ERP, au CRM ou aux systèmes d'usine n'a jamais été estimé.
  • Critères d'acceptation absents. Sans objectif formulé, le succès relève de l'opinion, et un projet qu'on ne peut pas déclarer réussi obtient rarement un financement supplémentaire.

Ce qu'un système de production exige au-delà de la démo

Une démo couvre le parcours principal. Un système de production doit aussi couvrir tout ce qui l'entoure. La liste ci-dessous correspond à ce que nous attendons avant la mise en service d'un système d'entreprise.

  • Authentification et autorisation, reliées au fournisseur d'identité de l'entreprise, avec des rôles qui correspondent à de vraies fonctions.
  • Journalisation et supervision qui permettent à un exploitant de voir les erreurs, les requêtes lentes et les traitements en échec avant que les utilisateurs ne les signalent.
  • Contrats de données qui définissent les champs, les formats, la fréquence de mise à jour et le comportement attendu lorsqu'un système amont envoie une valeur inattendue.
  • Procédures de déploiement et de retour arrière automatisées et répétées à l'avance, afin qu'une mauvaise version puisse être annulée en quelques minutes.
  • Documentation couvrant l'architecture, les interfaces, la configuration et les procédures d'exploitation.
  • Un responsable désigné, d'astreinte, disposant des accès et des connaissances nécessaires pour résoudre les incidents.

Comment structurer un projet par étapes

Une approche par étapes maintient chaque investissement à une échelle modeste par rapport à ce qui a été appris. La phase de cadrage vient en premier. Elle clarifie le problème métier, les personnes concernées, les systèmes impliqués et les données disponibles. Elle aboutit à un document court et à une décision de poursuivre ou non.

Le proof of concept suit, avec un critère d'acceptation mesurable fixé à l'avance. Pour un système de classification de documents, il peut s'agir d'une précision minimale sur un échantillon de test mis de côté. Pour un modèle de prévision, d'un seuil d'erreur par rapport à la méthode manuelle actuelle. L'objectif est d'obtenir une réponse claire, oui ou non.

Un pilote est ensuite mené sur des données réelles avec un groupe limité d'utilisateurs réels. C'est à ce stade qu'apparaissent les problèmes d'intégration, de qualité des données et de processus. La consolidation pour la production vient après : revue de sécurité, tests de performance, supervision, sauvegarde et restauration, chaîne de déploiement. La dernière étape est la passation, avec la formation, la documentation et un dispositif de support qui précise qui répond à quoi et dans quels délais.

Questions à poser à un prestataire avant de signer

Quelques questions directes apportent beaucoup d'informations à un acheteur. Qui, côté prestataire, reste sur le projet du cadrage à la passation. Quels sont les critères d'acceptation de chaque étape, et qui décide s'ils sont atteints. Comment le système sera supervisé après la mise en service, et qui est prévenu en cas de panne. À qui appartiennent le code source, les modèles entraînés et la documentation. Comment le système sera déployé, et comment une version défaillante est annulée.

Il est aussi légitime de demander quelles parties du travail dépendent du client, comme l'accès aux données, les environnements de test et les experts métier, et pour quelles dates. Les retards côté client sont une cause fréquente de dérive du calendrier, et les nommer dès le départ facilite leur gestion.

Conclusion

Passer du proof of concept à la production relève surtout de la responsabilité, des données, de l'intégration et de l'exploitation, et seulement en partie de la technologie présentée. Les organisations qui tranchent ces questions tôt, et qui structurent le travail avec des critères clairs, passent moins de temps dans des pilotes sans fin et davantage à faire fonctionner des systèmes sur lesquels les équipes s'appuient.