Idée

Un système compris est un système qu'on saurait reconstruire

Idée principale

Demander « est-ce que ça marche ? » à une application développée avec un assistant ne renseigne pas sur sa maîtrise : des écrans qui répondent, une base de données qui existe et une API qui tourne coexistent très bien avec des centaines de choix techniques que personne ne sait expliquer. La question qui discrimine est autre : saurait-on refaire ce système ailleurs, dans une autre technologie ?

Y répondre oui suppose de savoir où sont les contrats entre API, où vivent les règles métier, quels tests décrivent le comportement attendu plutôt que l'implémentation actuelle. Ces trois repères ne s'obtiennent pas après coup : ils s'imposent pendant la construction — exiger les contrats, faire produire les jeux de tests puis la pyramide de tests avant de développer, refuser que le métier soit dispersé dans les endpoints, même sans aller jusqu'à une démarche DDD complète que le projet ne justifie pas.

La reconstruction n'a pas à être entreprise. Elle sert de question de contrôle, et sa réponse mesure ce que l'équipe sait dire du système plutôt que ce que le système affiche.

Pourquoi c'est important

Cela donne un critère de qualité opposable là où la vitesse de livraison ne dit plus rien. Une démonstration fonctionnelle passe quel que soit l'état de la compréhension ; « saurais-je le reconstruire ? » échoue précisément quand elle manque.

Cela transforme aussi la compréhension en exigence de conception plutôt qu'en vertu individuelle : ce sont des lignes de séparation repérables qui la rendent possible, et elles se décident au moment où l'on construit.

Nuances et limites

Personne ne reconstruit pour vérifier qu'il aurait su le faire. Le critère reste donc une question posée en conscience, exposée à la complaisance de celui qui y répond — un système peut paraître reconstructible à qui l'a piloté et ne l'être pour personne d'autre.

Et il ne dit rien de la valeur du système : on peut savoir refaire à l'identique une application qui ne sert personne, ou dont l'architecture est médiocre.

Questions ouvertes

  • Quelle épreuve courte — reprendre un module par quelqu'un d'autre, réécrire un composant sans l'existant sous les yeux — donnerait à ce critère une vérification qui ne dépende pas de l'auto-évaluation ?