Le POC d'éditeur est une démo

Le POC est le moment où un choix de plateforme bascule, et c'est le moment le mieux maîtrisé... par l'éditeur. Son équipe avant-vente a déroulé le même scénario cinquante fois : les API d'exemple sont prêtes, les policies sont écrites, tout fonctionne en deux jours, tout le monde est impressionné.

Ce POC prouve une chose : que l'éditeur sait dérouler son scénario. Il ne dit à peu près rien de ce qui vous attend, parce que tout ce qui fait mal a été laissé hors du périmètre.

Ce qu'un POC d'éditeur ne montre jamais

• Vos API à vous. Le SOAP legacy avec ses en-têtes exotiques, le backend qui met quatre secondes à répondre, le contrat OpenAPI faux depuis deux ans. Le POC tourne sur des API de démonstration qui n'ont aucun de ces défauts.
• Votre chaîne de déploiement. La démo se fait dans la console. Votre vie se fera, on l'espère, dans une pipeline. La différence entre les deux est exactement l'endroit où les produits se départagent.
• Le deuxième jour. La montée de version, la panne d'un nœud, le certificat qui expire, la restauration depuis une sauvegarde. Rien de tout cela ne tient dans deux jours de démonstration.
• Vos équipes. Le POC est opéré par l'avant-vente. La production sera opérée par vos gens, avec leur niveau réel, un mardi soir.

L'épreuve, à la place

Un POC utile est écrit par vous, exécuté par vos équipes, sur vos cas. L'éditeur assiste et débloque, il ne pilote pas. Le scénario tient sur une page et il est le même pour tous les candidats, sinon vous ne comparez rien.

Le socle qu'on utilise en mission, à adapter :

1. Exposer trois de vos API réelles, dont la plus laide. Pas celles que vous êtes fiers de montrer : celles qui représentent le parc.
2. Dérouler le changement complet par la chaîne : modification de configuration dans Git, déploiement en recette, promotion en production, retour arrière. Chronométré, exécuté par un de vos ingénieurs, pas par l'avant-vente.
3. Casser quelque chose. Éteindre un nœud sous trafic, faire expirer un jeton, couper un backend. Regarder ce que voient les consommateurs et ce que voit l'exploitant.
4. Diagnostiquer une latence. Injecter 200 ms quelque part et mesurer le temps qu'il faut à l'équipe pour dire d'où ça vient, avec les seuls outils de la plateforme.
5. Faire souscrire un consommateur de bout en bout : découverte au portail, souscription, première requête qui réussit. Mesurer en minutes.

Chaque point produit un chiffre ou un constat, et la grille de comparaison se remplit avec des faits observés chez vous, pas avec les cases d'une brochure.

Le signal le plus fiable

Notez ce qui se passe quand quelque chose échoue pendant l'épreuve. C'est le moment le plus informatif de tout le processus de choix : la qualité des messages d'erreur, la profondeur de la documentation quand on sort du chemin nominal, la compétence réelle du support qu'on vous a promis.

Un produit dont la démo est brillante et dont les erreurs sont muettes vous prépare des nuits difficiles. L'inverse est un bien meilleur signe.

Le coût de l'épreuve

Deux à trois semaines par candidat, avec un ingénieur dédié à mi-temps. C'est cher, et c'est pour cela qu'on ne la fait passer qu'à deux finalistes, après un premier tri sur dossier.

Ce coût est à comparer au coût de l'erreur : une plateforme se choisit pour cinq à dix ans, et en changer sans couper le trafic est un chantier d'une autre échelle. Trois semaines d'épreuve sont la meilleure assurance du marché, et c'est très exactement le protocole qu'on installe quand on accompagne un choix de plateforme.