POC (preuve de concept)

Comment ça marche

Avant d’engager un projet d’IA, une question se pose : est-ce que ça va marcher sur nos données, nos documents, nos cas ? Les démonstrations des éditeurs tournent sur des exemples choisis. Le POC répond pour vous : on prend un échantillon réel, on fait tourner la technique envisagée, on mesure contre des critères fixés d’avance, et on conclut. Oui, non, ou oui à condition.

Le cadrage fait tout. Une question unique : « un modèle local peut-il répondre aux questions des techniciens à partir de nos procédures, avec 90 % de réponses correctes ? ». Un échantillon représentatif, y compris les cas difficiles. Des critères chiffrés, écrits avant de commencer. Une durée courte. Et une personne du métier qui juge les résultats. Ce qui sort du POC n’est pas un outil, c’est une décision documentée.

Un exemple concret

1. La question : un modèle ouvert, installé sur un serveur du laboratoire, peut-il résumer et classer les comptes rendus d’analyses aussi bien que le service en ligne utilisé jusque-là, sans que les données sortent ?
2. Le cadre : 200 comptes rendus anonymisés, deux semaines, un serveur loué pour l’occasion. Critères : au moins 90 % de classifications correctes et des résumés jugés « utilisables » par deux biologistes dans 85 % des cas.
3. Les résultats : classification 93 %. Résumés utilisables : 81 % avec le premier modèle, 88 % avec un modèle plus grand qui demande une machine plus puissante.
4. La décision : oui, avec le modèle plus grand et un serveur dimensionné en conséquence. Budget matériel chiffré, projet lancé. Le code du POC a été jeté ; les 200 comptes rendus annotés sont devenus le jeu d’évaluation du projet.

Deux semaines et un serveur loué ont évité d’acheter une machine sous-dimensionnée, ou de renoncer à tort.

Ce que ça change pour une équipe

• Les décisions se prennent sur des preuves. Pas sur une démonstration ni sur une promesse : sur vos données, avec vos critères.
• Le risque des projets baisse. On sait avant de s’engager si la technique tient, et à quel niveau.
• Le vocabulaire se clarifie. POC, puis MVP, puis produit : chacun sait à quelle étape on est, et ce qu’on en attend.
• Les échantillons annotés ont une seconde vie. Le jeu de données du POC devient le banc d’essai du projet.

Les limites et les erreurs fréquentes

• Le POC sans critères. « On verra si ça marche » finit en « ça a l’air pas mal » et en décision au feeling. Les critères s’écrivent avant.
• Le POC qui devient le produit. Il a l’air de marcher, on l’ouvre aux utilisateurs, et il casse sur le premier cas réel. Le POC prouve ; il ne sert pas.
• Un échantillon trop propre. Les 50 documents les mieux rédigés ne disent rien des 500 autres. L’échantillon inclut le pire.
• Le POC qui s’éternise. Six mois de POC, c’est un projet raté qui n’ose pas le dire. Une date de fin, et une décision à cette date.