VIEUX SCRIPT DÉTECTÉ

“Le design doit impressionner, pas être simple”

Essaie cette réponse :

“Ce qui est simple est plus fort : n'importe qui peut compliquer, mais expliquer une logique en trois lignes au lieu de trente, c'est rare.”

Faire l’auto-évaluation de 60 secondes →

VOIR LA PRATIQUE

Crée une réponse à cette pensée et un geste pour la mettre à l’épreuve.

LA PENSÉE

“Le design doit impressionner, pas être simple”

TA RÉPONSE ENREGISTRÉE

“Ce qui est simple est plus fort : n'importe qui peut compliquer, mais expliquer une logique en trois lignes au lieu de trente, c'est rare.”

UN PAS PRIVÉ

Choisis un design que tu crois impressionnant. Écris en trois paragraphes : 1) ce qu'il fait réellement, 2) pourquoi tu as choisi cette approche, 3) ce qu'un novice ferait différemment. Lis sans interruption. Cherche où tu dis « c'est compliqué parce que » au lieu de « c'est…

La présentation qui mange le déploiement

Avant : le brief arrive prêt à se résoudre

Tu lis le cahier des charges. C'est direct : afficher la liste des utilisateurs actifs, filtrer par date, exporter en CSV. Une semaine, deux écrans, une base de données existante. Puis tu penses : « Les autres vont voir ça et penser quoi ? » La solution brute paraît trop accessible. Tu commences à stratifier : un système de permissions custom, une abstraction de couche métier, une intégration d'API qui n'existe pas encore mais pourrait. Trois semaines plus tard, c'est séduisant. C'est ton design. C'est difficile de critiquer.

Après : le service devient une dépendance de toi

Six mois passent. Quelqu'un doit ajouter un champ à l'export. Il ouvre le code. L'abstraction a absorbé chaque choix. Il doit comprendre ta couche métier avant de toucher au CSV. Il demande. Tu expliques, parce que c'est plus rapide que d'écrire la documentation. Maintenant tu le sais : personne d'autre ne peut appuyer sur le bouton. La facturation mensuelle ? C'est toi qui la déploies. La migration qui fait peur ? C'est toi qui sais où elle bifurque. Tu as construit une forteresse où tu es le seul gardien. L'entreprise l'appelle criticalité. Tu sais que c'est autrement : la sécurité d'emploi comme un pont qui s'écroule si tu le traverses…

Preuve : lire le code sans avoir besoin de toi d'abord

Ouvre ton dernier design critiqué comme impressionnant. Isolé, sans toi. Pourrais-tu le lire en cinq minutes sans notes, sans slack ? Non ? C'est la réponse. Maintenant, rédige à côté une version où un collègue pourrait le cerner en ce même laps. Pas bête. Juste visible. Poste-la nulle part. Lis-la seul. Observe : on peut la critiquer parce qu'on la comprend d'abord.

TRACE · 01/04

Comment ce script te dirige

Tu ajoutes une couche d'abstraction surtout parce qu'elle paraît plus digne d'être examinée, même si le problème n'en demandait pas.
Les tâches qui semblent critiques pour l'entreprise restent entre tes mains parce qu'on ne peut pas les transmettre sans perte de contexte secret.
Intégrer quelqu'un sur ton système équivaut à rédiger un document où chaque pas dépend de ton interprétation des choix passés.

SOURCE_LOCATED · 02/04

La règle cachée en dessous

La Preuve d'Indispensabilité

« Si le système n'a pas besoin de moi pour être compris et maintenu, l'entreprise n'a pas besoin de moi non plus. » Alors on complique volontairement, on garde les détails critiques pour soi, et on appelle ça de la séniorité plutôt que d'admettre qu'on a construit un point de défaillance unique comme garantie de présence.

FORGING_REPLACEMENT · 03/04

Lignes de remplacement (à enregistrer)

Ce qui est simple est plus fort : n'importe qui peut compliquer, mais expliquer une logique en trois lignes au lieu de trente, c'est rare.
Transmettre ce que j'ai fait prouve que j'ai construit quelque chose de solide, pas que je suis remplaçable ; c'est le marqueur d'un travail senior.
Ma valeur réside dans le problème suivant que je résous, pas dans celui que je garde enfermé.

Générées par personne dans l'app — ceci donne le ton, pas ton script. Le tien se construit à partir de tes mots exacts.

INSTALL · 04/04

Le protocole, sur une carte

Quand je pense

“Le design doit impressionner, pas être simple”

Je dis

“Ce qui est simple est plus fort : n'importe qui peut compliquer, mais expliquer une logique en trois lignes au lieu de trente, c'est rare.”

Puis je fais une chose

STATUS: READY_TO_INSTALL

Effacer cette pensée

4 minutes. Ta voix. Gratuit.

Lancer ce wipe précis dans l'app →

Le protocole de wipe

Écris la pensée exactement comme elle tourne : « Le design doit impressionner, pas être simple ». Mot pour mot — le wipe vise la phrase, pas l'ambiance.
Repère la règle et l'action évitée. De quoi cette pensée t'excuse-t-elle si commodément ?
Enregistre les lignes de remplacement ci-dessous avec ta propre voix. Parle pour de vrai — pas d'enregistrement, pas d'installation.
Fais tourner la boucle : écoute matin et soir, note une action-preuve par jour pendant 7 jours.

Réponses directes

Comment je sais si j'ajoute de la complexité pour impressionner ou si c'est vraiment nécessaire ?

Si tu peux expliquer le choix d'architecture à quelqu'un qui découvre le code en deux minutes, c'était nécessaire. Si tu dois d'abord parler de contexte, de raisons historiques, d'autres systèmes qui auraient échoué, tu as construit pour convaincre, pas pour résoudre.

Mais si je simplifie trop, ne vais-je pas paraître junior ou inexpérimenté ?

L'inverse : la clarté exige plus de discernement que la complexité. N'importe qui peut ajouter une couche. Choisir exactement ce qui résout le problème sans ornement, c'est ce qui s'apprend en années. C'est visible par celui qui lit, pas par celui qui craint d'être lu.

Qu'est-ce que je fais si quelqu'un me dit que mon design est trop simple, pas assez ambitieux ?

Demande : « Où cela échoue-t-il à faire ce qu'on lui demande ? » Si la réponse est « nulle part, mais c'est basique », tu as une preuve. Un design qui complète la tâche est ambitieux. Un design qui prolonge ta nécessité est une dépense.