Faire monter l'atelier avant la première ligne de code

Quand l’employer

À employer une fois l'architecture décidée et avant le premier incrément. À ne pas employer après avoir commencé à construire : rattraper un atelier absent coûte davantage que de le monter.

Les 4 trous à remplir avant d’envoyer

Chaque trou est une décision déjà prise. Un trou que vous ne savez pas remplir n’est pas une case à improviser : c’est un travail de cadrage qui manque.

{PILE_DECIDEE}

Quels choix techniques ont été arrêtés, et par quelle décision écrite ?

Pourquoi ce trou existe. Un atelier monté sur des choix non arrêtés se remonte entièrement à la première décision contraire.

Si vous ne savez pas répondre. Revenez à la phase d'architecture. Monter l'atelier avant de trancher revient à trancher par défaut, sans l'avoir décidé.

{ENVIRONNEMENTS_VOULUS}

Combien d'environnements séparés voulez-vous, et lequel porte de vraies données ?

Pourquoi ce trou existe. Sans séparation déclarée, tout se fait au même endroit, et le premier essai malheureux touche les données réelles.

Si vous ne savez pas répondre. Prenez-en deux au minimum : un pour essayer, un pour de vrai, avec des identifiants différents et aucune donnée réelle du côté essai.

{SECRETS_A_CONSERVER}

Quelles clés, quels mots de passe et quels accès faudra-t-il conserver, et où ?

Pourquoi ce trou existe. Les secrets se rangent dès le premier jour. Rangés plus tard, ils sont déjà passés dans l'historique du dépôt, où ils restent.

Si vous ne savez pas répondre. Décidez d'abord la règle : aucun secret dans le dépôt, jamais, sous aucun prétexte. Le rangement suit cette règle, pas l'inverse.

{PORTE_AUTOMATIQUE}

Quels contrôles doivent bloquer automatiquement une livraison non conforme ?

Pourquoi ce trou existe. Un contrôle qui n'est pas automatique n'est pas un contrôle : c'est une bonne intention que la fatigue supprime.

Si vous ne savez pas répondre. Commencez par trois : le projet se construit, les tests passent, aucun secret n'est présent dans les fichiers ajoutés.

Le corps du gabarit

Quatre parties, toujours dans cet ordre : le rôle et le mandat, le contexte factuel, la demande bornée, le format de sortie exigé. Les trous restent visibles à la copie, et c’est voulu : les remplir un par un est la dernière occasion de s’apercevoir qu’une décision manque.

## 1. RÔLE ET MANDAT

Tu es responsable de l'exploitation. Ton mandat est de monter l'atelier dans lequel le travail sera fait : dépôt, environnements séparés, rangement des secrets, contrôles automatiques. Tu ne construis aucune fonctionnalité du produit.

## 2. CONTEXTE FACTUEL

Choix techniques arrêtés : {PILE_DECIDEE}
Environnements voulus et celui qui porte de vraies données : {ENVIRONNEMENTS_VOULUS}
Secrets à conserver : {SECRETS_A_CONSERVER}
Contrôles qui doivent bloquer automatiquement : {PORTE_AUTOMATIQUE}

Aucun secret n'entre dans le dépôt, à aucun moment, même temporairement, même dans un fichier d'exemple contenant une valeur réelle.

## 3. DEMANDE BORNÉE

Monte l'atelier.

Ce que je veux :
1. le dépôt initialisé, avec la liste des fichiers et dossiers exclus du suivi, et la raison de chaque exclusion ;
2. les environnements séparés, avec pour chacun ce qui le distingue et ce qu'il a le droit de contenir ;
3. le rangement des secrets, avec un fichier d'exemple contenant les noms des variables et aucune valeur réelle ;
4. les contrôles automatiques demandés, chacun devant faire échouer la livraison quand il n'est pas satisfait ;
5. la démonstration que la porte bloque : ce que je fais pour provoquer volontairement un échec et le voir bloquer ;
6. la marche à suivre pour qu'une autre personne installe le projet sur sa machine, du début à la fin.

Ce que je ne veux pas : une fonctionnalité du produit, un contrôle qui avertit sans bloquer, une valeur réelle dans un fichier d'exemple, un environnement d'essai branché sur les données réelles.

## 4. FORMAT DE SORTIE EXIGÉ

La démonstration que la porte bloque est obligatoire et vient en dernier. Elle décrit une erreur à introduire volontairement, et le message exact que je dois voir. La marche d'installation est numérotée et testée depuis un dossier vide.

Ta réponse est refusable si un contrôle avertit au lieu de bloquer, si le fichier d'exemple contient une valeur réelle, ou si la démonstration de blocage est absente.

Ce que vous devez recevoir

• Un dépôt initialisé, avec la raison écrite de chaque exclusion de suivi.
• Des environnements séparés, chacun avec ce qu'il a le droit de contenir.
• Un fichier d'exemple portant les noms des variables et aucune valeur réelle.
• Des contrôles qui font échouer la livraison, jamais des contrôles qui avertissent.
• Une démonstration de blocage : l'erreur à provoquer et le message exact à voir.
• Une marche d'installation numérotée, vérifiable depuis un dossier vide.

Ce qui doit vous faire refuser

Ces motifs sont écrits comme des constats : « un fichier hors périmètre a été modifié » se vérifie, « le travail manque de rigueur » ne se vérifie pas.

• Un contrôle avertit au lieu de bloquer, ce qui le rend décoratif dès la première semaine chargée.
• Le fichier d'exemple contient une valeur réelle, donc un secret est entré dans le dépôt.
• La démonstration de blocage manque, et vous ne savez donc pas si la porte fonctionne.
• L'environnement d'essai pointe sur les données réelles, ce qui annule la séparation.
• La marche d'installation suppose des outils déjà présents sans le dire.
• L'agent a construit une fonctionnalité du produit alors que seul l'atelier était demandé.

Selon pour qui vous construisez

Pour moi.

Deux environnements suffisent, mais la séparation doit être réelle : deux bases distinctes, deux jeux d'identifiants. Un préfixe dans les noms ne sépare rien.

Pour mon employeur.

L'atelier respecte les règles de l'organisation sur les dépôts et les accès. Faites-les écrire avant, plutôt que de découvrir un refus à la mise en service.

Pour un client.

Décidez dès le premier jour à qui appartient le dépôt à la fin du contrat, et écrivez-le. Cette question non tranchée envenime toutes les fins de mission.