Un contrat d’interface, pas un prototype
La confusion la plus fréquente est de ranger le playground avec les outils de prototypage. C’en est l’inverse. Un prototype sert à valider une intention puis à être jeté. Le playground produit le code réel du produit, celui que le développeur branchera, pas une représentation qu’il faudra retraduire.
La distinction avec le design-to-code compte tout autant. Le design-to-code génère du code à partir d’une maquette, avec le risque classique du code généré qui s’éloigne du codebase. Le playground-driven design travaille directement dans le codebase : c’est du design-in-code. Ce que le designer voit dans le playground est exactement ce qui partira en production, parce que c’est la vraie vue qui rend, pas une copie.
Ce qui fait la valeur n’est donc pas la vitesse de prototypage, c’est le contrat : au moment où le développeur ouvre l’écran pour brancher l’API, tous les états sont déjà implémentés et validés dans la vraie vue. Le moment habituel où il ré-implémente ces états depuis une maquette statique, et où l’écart se règle au coup par coup avec le design, disparaît.
La règle de souveraineté
La méthode tient sur une règle qui protège les deux métiers : le designer ne touche jamais à la logique backend ni aux appels API, le développeur ne reconstruit jamais le visuel depuis zéro. Chacun intervient sur sa couche.
Ce découplage est d’abord temporel. Le visuel et tous ses états avancent pendant que l’API n’existe pas encore, puis le branchement vient se poser sur une structure déjà complète. Ce n’est pas une prise de pouvoir du design sur l’engineering, c’est une réorganisation de l’ordre dans lequel les choses se décident. Nommer cette règle explicitement évite le malentendu le plus coûteux, celui qui ferait lire la méthode comme une intrusion plutôt que comme une collaboration mieux séquencée.
Les conditions qui rendent la méthode viable
Le piège serait de promettre une réplication identique partout. L’intention et la grille sont portables, l’implémentation reste spécifique à chaque stack. Avant de déployer la méthode, mieux vaut diagnostiquer six conditions, qui relèvent des pratiques de la squad plus que d’un aléa. Ce sont elles que le diagnostic plus haut donne à évaluer une à une.
Les deux premières sont des fondations : si le découplage front/back ou la couche mockable manquent, le playground n’est pas le premier chantier. Les autres sont des accélérateurs. La condition de preview automatisé est souvent celle qui manque, et ce n’est pas bloquant : le playground tourne en local sans elle, elle ne sert qu’à rendre le rendu visible sans récupérer la branche.
Poser ces six conditions sous forme de grille à remplir transforme la conversation. On ne promet pas une méthode qui casserait sur une stack non découplée, et on ne se fait pas refuser la méthode alors que le vrai blocage est une condition d’infrastructure nommable et budgétable.
Vendre la grille, pas l’outil
Trois principes aident à défendre la méthode au-delà de sa première application.
Auditer avant de demander change la nature de la demande. On n’arrive pas en réclamant des accès, on arrive avec une lecture du code et une proposition de collaboration informée. Montrer avant d’argumenter, ensuite : une démo de cinq minutes du playground pèse plus qu’un document de trois pages avec des cases à cocher. L’ordre qui fonctionne va de la démo vers le one-pager de leadership, puis vers la diffusion.
Le point le plus structurant est le dernier : c’est la grille de readiness qui s’installe sur la table à chaque nouvelle squad, pas le playground. Le playground est le résultat quand le score le permet, la grille est l’entrée de discussion. Ce déplacement protège des deux échecs symétriques, promettre une réplication qui se brise, ou se voir refuser la méthode pour une raison qui n’avait jamais été nommée.