Une démo est un début. La preuve vient après.
Ce que je regarde entre une fonctionnalité qui impressionne et un système sur lequel une équipe peut s’appuyer.
Dire exactement ce qui fonctionne
Une démonstration doit permettre de comprendre une idée rapidement. Elle peut utiliser des données simulées, une intégration partielle ou un environnement local. Le problème commence quand ces conditions disparaissent du récit.
Dans mon portfolio, les statuts font partie de la présentation. Un prototype produit, un dossier de recherche et une infrastructure publiée sur testnet montrent des compétences différentes. Ils méritent d’être décrits pour ce qu’ils permettent réellement de vérifier.
Rendre les transitions vérifiables
Avec Grindy Campaign Rails, le parcours est découpé : lire un événement, le normaliser, déterminer son éligibilité, produire une allocation et régler la récompense. Chaque passage a un contrat explicite. Le dépôt public conserve des fixtures et des références de transactions testnet pour documenter ce parcours.
Cette façon de construire vaut aussi pour les agents. Une entrée acceptée ne garantit pas une analyse correcte. Une analyse terminée ne donne pas automatiquement le droit d’agir. Il faut pouvoir examiner la transition, ses conditions et ses conséquences.
Tester autre chose que le scénario heureux
Je veux savoir ce qu’une seconde exécution produit, ce qu’un utilisateur non autorisé peut obtenir et comment le système reprend après une interruption. Sur une application de collection comme PokeMarketCap, rejouer un mouvement ne doit pas doubler un stock. Sur un workflow agentique, rejouer un reçu ne doit pas dupliquer une livraison.
Les tests utiles protègent une règle métier. Ils ne remplacent pas l’essai sur un appareil réel, l’examen de sécurité ou la confrontation aux usages. Chaque méthode apporte une pièce de preuve, avec son périmètre.
Une culture de l’examen
Mon dossier public sur P vs NP aborde le même sujet sous un angle théorique : distinguer un récit plausible d’un résultat démontré. Il ne propose aucune percée. Il rassemble des barrières de preuve, des références et les limites de certains discours sur l’IA et le quantique.
Pour une organisation, cette exigence est pratique. Elle aide à décider ce que l’on peut essayer, ce que l’on peut livrer et ce que l’on doit encore vérifier. Je veux construire des systèmes ambitieux, avec une description précise de ce qui les rend fiables.