Prototype (POC)

À quoi il sert

Un prototype ne cherche pas à démontrer qu'une technologie existe, mais qu'elle apporte quelque chose sur un cas identifié. Il prend une tâche réelle, un volume limité de documents et un utilisateur qui connaît le métier, puis il mesure. Le résultat attendu n'est pas une application aboutie : c'est une réponse argumentée à une question de décision, du type faut-il industrialiser ce traitement ou vaut-il mieux l'abandonner ? La réponse tient en quelques pages, avec des chiffres et des exemples, pas en une démonstration spectaculaire.

Cette étape évite deux dépenses inutiles. Elle empêche de lancer un développement lourd sur une intuition non vérifiée, et elle empêche d'écarter un sujet prometteur à cause d'un essai bâclé. Dans les deux cas, le coût du prototype reste modeste au regard de celui d'un projet mal engagé. C'est aussi le moyen de faire exister le sujet dans l'entreprise : un dirigeant qui voit son propre courrier traité comprend plus vite qu'avec un diaporama.

Comment le cadrer

Le cadrage commence par le choix de la tâche. Elle doit être fréquente, chronophage, et son résultat doit être vérifiable par un humain compétent. Une tâche rare, mal définie ou impossible à contrôler ne donnera aucun enseignement. Il faut ensuite constituer un jeu de cas réels, y compris des cas difficiles, et fixer dès le départ le critère de succès : temps gagné, taux de réponses acceptées sans correction, nombre de dossiers traités par jour, part des sorties acceptées telles quelles.

Le périmètre doit rester étroit, avec une durée annoncée à l'avance. Mélanger plusieurs cas d'usage dans un même prototype dilue la mesure et complique la démonstration. Mieux vaut deux prototypes successifs qu'un seul trop ambitieux. Enfin, l'utilisateur final doit être associé au test, pas seulement consulté à la fin : c'est lui qui dira si la sortie est utilisable dans son travail quotidien, et son adhésion conditionne la suite du projet.

Ce qu'il ne prouve pas

Un prototype réussi ne garantit pas une industrialisation simple. Il ne dit rien de la charge à cent utilisateurs, ni du coût mensuel à l'échelle, ni de la maintenance des modèles dans le temps. Il ne traite pas non plus les sujets de droits d'accès, de journalisation ou de conservation des données, qui deviennent centraux dès la mise en service. Ces questions doivent être posées au moment de la décision, pas découvertes en production, sous la pression d'un calendrier déjà engagé.

Il ne prouve pas non plus l'adhésion des équipes. Un outil validé techniquement peut rester inutilisé si personne n'a été formé, si le circuit de validation n'est pas adapté ou si l'outil ajoute une étape au lieu d'en retirer. La décision d'industrialiser se prend donc sur trois plans : la qualité mesurée, le coût complet et les conditions d'usage. Un prototype qui échoue sur le premier point reste utile, car il a évité un investissement inutile.