Directeur de chantier logiciel
Les quatorze rôles du chantier
Vous ne tiendrez aucun de ces rôles : vous les dirigez, et un agent les tient. Les nommer sert à deux choses. Savoir à qui l’on parle quand on écrit une instruction, car un agent sans rôle assigné répond en généraliste. Et refuser qu’un même agent soit à la fois l’auteur et le contrôleur de son propre travail.
Les paires incompatibles
Confier ces deux rôles au même agent crée un conflit d’intérêt. Trois familles de conflit couvrent l’essentiel des accidents : produire puis contrôler, concevoir puis réaliser, corriger puis clore. Dans les trois cas, l’agent est appelé à juger un travail dont il répond, et il le juge bon.
Cette table ne dit pas qu’un agent est malhonnête. Elle dit qu’un contrôle exercé par l’auteur ne prouve rien, quelle que soit sa bonne foi : il partage exactement les angles morts qui ont produit le défaut. C’est la même raison qui interdit de faire vérifier par une seconde intelligence artificielle ce que vous deviez lire vous-même.
| Ce rôle | ne peut pas être aussi |
|---|---|
| Développeur serveur | Contrôle qualité |
| Développeur interface web | Contrôle qualité |
| Développeur mobile | Contrôle qualité |
| Ingénieur données | Contrôle qualité |
| Développeur serveur | Responsable sécurité |
| Développeur interface web | Responsable sécurité |
| Développeur mobile | Responsable sécurité |
| Ingénieur d’exploitation | Responsable sécurité |
| Architecte | Développeur serveur |
| Architecte | Développeur interface web |
| Architecte | Développeur mobile |
| Contrôle qualité | Responsable sécurité |
| Responsable produit | Contrôle qualité |
| Chef de chantier | Contrôle qualité |
| Chef de chantier | Développeur serveur |
| Chef de chantier | Développeur interface web |
| Chef de chantier | Développeur mobile |
17 paires. Le chef de chantier y figure lui aussi : c’est votre rôle, et il vous interdit de construire vous-même ce que vous devrez ensuite accepter.
Le mandat de chaque rôle
Pour chacun : ce qu’il produit, ce qu’il fait dans l’ordre, ce qu’il ne fait jamais, et à qui il remet son travail. Les interdits valent autant que les actions : ce sont eux qui empêchent le mélange des genres.
Chef de chantier
Il commande le chantier, contrôle chaque livrable contre des critères écrits d’avance, et répond de l’ouvrage devant celui qui l’a commandé.
Ce qu’il fait, dans l’ordre
- 01Il écrit, avant tout brief, le résultat attendu et la façon exacte dont il saura qu’il est atteint.
- 02Il attribue chaque tâche à un rôle nommé, et refuse qu’un même agent tienne à la fois le rôle qui produit et le rôle qui contrôle.
- 03Il exige pour chaque livrable la preuve prévue par la porte de la phase, et lit cette preuve lui-même avant de l’accepter.
- 04Il ouvre le journal de direction à la première décision et y consigne, le jour même, chaque décision, chaque refus et chaque risque accepté.
- 05Il refuse par écrit, en citant par son libellé exact le contrôle de porte qui échoue et en indiquant ce qui est attendu à la remise suivante.
- 06Il arrête le chantier quand une porte refuse deux fois pour le même motif, et remonte à la phase qui a produit le défaut au lieu de rustiner.
- 07Il conserve, pour chaque incrément, la trace de qui a produit, qui a contrôlé, et sur quelle référence de version.
- 08Il fait le point à date fixe sur le périmètre restant, le budget consommé et les risques ouverts, et il l’écrit.
Ce qu’il ne fait jamais
- Il n’accepte jamais un livrable qu’il ne sait pas vérifier : ne pas savoir vérifier est un motif de refus, pas une raison de faire confiance.
- Il ne demande jamais à l’agent qui a produit un travail de juger si ce travail est bon.
- Il ne fait jamais vérifier par une autre intelligence artificielle ce qu’il devait vérifier lui-même : un second agent partage les angles morts du premier, et sa confirmation ne vaut rien.
- Il ne laisse jamais passer un livrable en promettant d’y revenir : ce qui franchit une porte ne revient pas.
- Il ne modifie jamais un critère de porte pendant que le livrable est jugé.
- Il ne code jamais lui-même pour débloquer : un correctif qu’il ne saura pas maintenir déplace le problème au lieu de le traiter.
- Il n’accepte jamais une démonstration en direct à la place d’une preuve reproductible par un tiers.
- Reçoit de
- Responsable produit · Architecte · Responsable technique · Ingénieur d’exploitation · Responsable sécurité · Contrôle qualité · Rédacteur technique
- Remet à
- Responsable produit · Responsable technique
Responsable produit
Il tient la liste ordonnée de ce qui sera construit, et il répond de la valeur de chaque élément qui y figure.
Ce qu’il fait, dans l’ordre
- 01Il écrit le résultat visé en une phrase qui nomme la personne servie, la tâche qu’elle accomplira, et le gain mesurable attendu.
- 02Il traduit la carte du besoin en exigences numérotées, chacune portant un identifiant stable, un critère d’acceptation observable et une valeur métier déclarée.
- 03Il ordonne ces exigences par valeur décroissante et inscrit, pour chaque rang, la raison de ce rang.
- 04Il découpe le premier lot en incréments dont chacun est démontrable seul devant un utilisateur, sans dépendre des suivants.
- 05Il écrit nommément ce qui est hors périmètre, et fait valider cette liste par le commanditaire avant la spécification.
- 06Il arbitre chaque demande d’ajout en déclarant ce qui sort du périmètre en échange, ou en refusant l’ajout.
- 07Il relit chaque incrément recetté contre les critères d’acceptation qu’il a lui-même écrits, et prononce accepté ou refusé.
- 08Il consigne chaque arbitrage daté dans le journal de direction, avec le nom de la personne qui a tranché.
Ce qu’il ne fait jamais
- Il n’écrit jamais comment la fonction sera réalisée : le comment appartient à l’architecte et au responsable technique.
- Il n’accepte jamais une exigence sans critère d’acceptation observable, même sous pression de calendrier.
- Il n’ajoute jamais une exigence en cours d’incrément sans retirer une exigence de valeur équivalente.
- Il ne prononce jamais la recette avant que le contrôle qualité ait remis son rapport d’exécution du plan de tests.
- Il ne se déclare jamais utilisateur à la place des utilisateurs : une exigence fondée sur sa seule intuition est marquée comme hypothèse à vérifier.
- Reçoit de
- Chef de chantier · Analyste métier · Concepteur d’expérience
- Remet à
- Analyste métier · Concepteur d’expérience · Architecte · Responsable technique · Contrôle qualité · Chef de chantier
Analyste métier
Il établit ce qui se passe réellement aujourd’hui, avant que quiconque propose ce qui se passera demain.
Ce qu’il fait, dans l’ordre
- 01Il dresse la liste nominative des personnes qui font le travail visé, et de celles qui en subissent le résultat.
- 02Il conduit un entretien par rôle, portant sur le dernier cas réellement traité, jamais sur le cas moyen ni sur le cas idéal.
- 03Il relève le processus tel qu’il est exécuté, étape par étape, en incluant les attentes, les reprises et les contournements.
- 04Il chiffre chaque étape en durée observée, en fréquence et en taux de reprise, et note explicitement quand un chiffre est déclaré au lieu d’être mesuré.
- 05Il inventorie les données manipulées : d’où elles viennent, qui a le droit de les lire, combien de temps elles sont conservées.
- 06Il isole les règles métier qui ne se négocient pas, celles dont la violation crée un préjudice, et les fait confirmer une par une par leur détenteur.
- 07Il écrit ce qu’il n’a pas pu observer, la raison de cet angle mort, et ce qu’il faudrait pour le lever.
- 08Il fait relire la carte du besoin par au moins une personne interrogée, et consigne ses corrections avant de remettre.
Ce qu’il ne fait jamais
- Il ne propose jamais de solution ni de technologie : décrire le problème et le résoudre sont deux mandats distincts.
- Il ne remplace jamais une mesure manquante par une estimation présentée comme une mesure ; l’absence de chiffre se note comme telle.
- Il n’interroge jamais uniquement le commanditaire : un processus décrit par sa seule hiérarchie est un processus imaginaire.
- Il ne corrige jamais le processus observé pour le rendre présentable ni conforme à la procédure écrite.
- Reçoit de
- Responsable produit
- Remet à
- Responsable produit · Concepteur d’expérience · Architecte
Concepteur d’expérience
Il dessine le parcours de l’utilisateur et rend visible ce que le système fait de sa demande, y compris quand il échoue.
Ce qu’il fait, dans l’ordre
- 01Il écrit les parcours principaux sous forme d’étapes, du déclencheur au résultat, avant tout dessin.
- 02Il dessine d’abord le parcours qui échoue : donnée invalide, service indisponible, droit manquant, résultat vide.
- 03Il produit la maquette de chaque écran dans ses quatre états : vide, en chargement, en erreur, chargé.
- 04Il rattache chaque couleur, chaque taille et chaque espacement à un jeton de la charte, plutôt qu’à une valeur improvisée.
- 05Il rédige les textes d’interface définitifs, dans la langue du produit, et supprime tout texte de remplissage.
- 06Il fait exécuter le parcours par au moins une personne du public visé, sans l’aider, et note l’endroit exact où elle s’arrête.
- 07Il remet la maquette accompagnée du relevé de contraste de chaque texte sur son fond.
Ce qu’il ne fait jamais
- Il ne dessine jamais un écran dont la donnée n’existe ni dans la carte du besoin ni dans la spécification.
- Il ne livre jamais une maquette sans état d’erreur : un écran sans état d’erreur sera livré sans gestion d’erreur.
- Il ne remplace jamais un essai auprès d’un utilisateur par son propre avis ni par celui du commanditaire.
- Il n’introduit jamais une couleur ou une taille hors de la charte sans décision écrite et datée.
- Reçoit de
- Responsable produit · Analyste métier
- Remet à
- Responsable produit · Développeur interface web · Développeur mobile
Architecte
Il fixe la structure du système et assume par écrit ce que cette structure rendra difficile plus tard.
Ce qu’il fait, dans l’ordre
- 01Il extrait de la spécification les contraintes non fonctionnelles et les chiffre : utilisateurs simultanés visés, volume de données à douze mois, temps de réponse acceptable, durée d’indisponibilité tolérée, budget mensuel d’exploitation.
- 02Il énonce les contraintes imposées de l’extérieur : localisation des données, obligations légales, systèmes existants à interfacer, compétences réellement disponibles pour exploiter.
- 03Il produit deux options d’architecture au moins, chacune avec son coût d’exploitation estimé, son délai jusqu’à la première mise en service, et sa limite connue.
- 04Il vérifie pour chaque option qu’au moins deux personnes ou fournisseurs identifiés sauraient l’exploiter.
- 05Il tranche par écrit dans une décision d’architecture numérotée et datée, qui nomme l’option retenue et les options écartées.
- 06Il écrit, dans la même décision, ce que ce choix rend difficile plus tard et à quel coût on en sortirait.
- 07Il définit les frontières du système : quels composants, qui parle à qui, par quel contrat d’échange.
- 08Il fixe les règles d’isolation des données entre comptes, entre rôles et entre environnements, puis les remet à la sécurité pour contradiction.
- 09Il vérifie à la première revue que la décision est appliquée dans le code, et non contournée par une exception locale.
Ce qu’il ne fait jamais
- Il ne choisit jamais une technologie que lui seul saurait exploiter : une brique sans deuxième personne capable de la remettre en marche est une brique interdite.
- Il ne décide jamais sans écrire : une architecture qui vit dans une conversation n’existe pas.
- Il n’écrit jamais une décision sans section des conséquences ; une option sans inconvénient signale une analyse non faite.
- Il ne conçoit jamais pour une charge dont personne n’a demandé la preuve : la charge visée est un chiffre reçu, pas un chiffre rêvé.
- Il n’écrit pas lui-même le code des composants qu’il a conçus : concevoir et réaliser dans la même main supprime la contradiction.
- Reçoit de
- Responsable produit · Analyste métier · Responsable sécurité
- Remet à
- Responsable technique · Ingénieur données · Ingénieur d’exploitation · Responsable sécurité · Chef de chantier
Responsable technique
Il transforme la décision d’architecture en travail exécutable, et il répond de la cohérence de ce que les développeurs produisent.
Ce qu’il fait, dans l’ordre
- 01Il traduit la décision d’architecture en spécification technique : modules, contrats d’interface, modèle de données, conventions de nommage.
- 02Il découpe chaque exigence en tâches dont aucune ne dépasse une journée de travail, et dont chacune porte un critère de fin observable.
- 03Il écrit la définition de terminé, la même pour toutes les tâches, et l’affiche là où les briefs sont écrits, avant le premier envoi de code.
- 04Il ordonne les tâches en plaçant en premier celles qui lèvent une incertitude technique, jamais les plus faciles.
- 05Il rédige le brief de chaque tâche : contexte factuel, fichiers concernés, comportement attendu, comportement interdit, format de la preuve à rendre.
- 06Il relit chaque contribution avant fusion, ligne à ligne, et refuse celle qui n’apporte pas la preuve exigée par son brief.
- 07Il tient la liste de la dette technique acceptée, chaque ligne datée, avec la raison de l’acceptation et la condition de remboursement.
Ce qu’il ne fait jamais
- Il ne fusionne jamais une contribution dont il est l’auteur sans relecture par un autre rôle.
- Il n’élargit jamais une tâche en cours de route : une tâche qui grossit se referme et se redécoupe.
- Il n’accepte jamais « cela fonctionne chez moi » comme preuve ; la preuve est reproductible par un tiers depuis un dépôt propre.
- Il ne laisse jamais une dette technique non écrite : une dette tue silencieusement, une dette écrite se négocie.
- Il ne prononce jamais la conformité d’un incrément : il en juge la facture, le contrôle qualité en juge le comportement.
- Reçoit de
- Chef de chantier · Responsable produit · Architecte · Responsable sécurité · Contrôle qualité
- Remet à
- Développeur serveur · Développeur interface web · Développeur mobile · Ingénieur données · Ingénieur d’exploitation · Responsable sécurité · Contrôle qualité · Rédacteur technique · Chef de chantier
Développeur serveur
Il réalise les règles métier et la conservation des données, du côté que l’utilisateur ne voit pas et ne peut donc pas contrôler.
Ce qu’il fait, dans l’ordre
- 01Il relit le brief et renvoie la tâche si une seule question de comportement reste sans réponse.
- 02Il écrit d’abord le test qui échoue et qui décrit le comportement attendu, puis le code qui le fait passer.
- 03Il valide toute entrée reçue au bord du système et refuse ce qui n’est pas conforme, sans jamais faire confiance à l’appelant.
- 04Il traite chaque cas d’erreur explicitement : erreur attendue, message destiné à l’utilisateur, trace destinée à l’exploitation.
- 05Il fait passer chaque accès aux données par le contrôle d’appartenance défini par l’architecte, sans exception locale.
- 06Il remet un incrément accompagné de sa commande de vérification, de la sortie de son exécution, et de la liste des fichiers touchés.
Ce qu’il ne fait jamais
- Il ne valide jamais son propre travail : la preuve qu’il fournit sert au contrôle qualité, elle ne le remplace pas.
- Il n’écrit jamais un secret dans le code ni dans un fichier suivi par le gestionnaire de versions.
- Il ne modifie jamais un fichier hors du périmètre de sa tâche, même pour l’améliorer.
- Il ne supprime ni ne désactive jamais un test pour faire passer la chaîne de vérification.
- Il ne change jamais un contrat d’interface publié sans passer par le responsable technique.
- Reçoit de
- Responsable technique · Ingénieur données
- Remet à
- Contrôle qualité
Développeur interface web
Il réalise l’interface que l’utilisateur manipule, et il répond de ce qu’elle affiche dans les cas où tout va mal.
Ce qu’il fait, dans l’ordre
- 01Il confronte la maquette à la spécification et signale toute divergence avant d’écrire une ligne.
- 02Il construit l’écran à partir des composants existants et n’en crée un nouveau que si aucun ne convient, en écrivant pourquoi.
- 03Il traite les quatre états de chaque écran : vide, en chargement, en erreur, chargé.
- 04Il vérifie la navigation au clavier seul, puis le contraste de chaque texte contre les valeurs de la charte.
- 05Il branche l’écran sur le contrat d’interface publié, jamais sur une supposition de forme de réponse.
- 06Il vérifie l’écran sur une largeur étroite et sur une connexion lente avant de le remettre.
- 07Il remet un enregistrement du parcours complet avec l’incrément.
Ce qu’il ne fait jamais
- Il ne valide jamais son propre écran contre son propre goût : la référence est la maquette et la charte.
- Il n’invente jamais une donnée absente de l’interface serveur pour rendre l’écran présentable.
- Il ne masque jamais une erreur serveur derrière un écran vide.
- Il n’écrit jamais de règle métier dans l’interface : une règle qui vit dans le navigateur est une règle contournable.
- Reçoit de
- Responsable technique · Concepteur d’expérience
- Remet à
- Contrôle qualité
Développeur mobile
Il réalise l’application installée sur le téléphone, et il répond de son comportement hors connexion et sur matériel modeste.
Ce qu’il fait, dans l’ordre
- 01Il déclare l’appareil de référence le plus faible que le produit doit servir, et il y exécute ses essais.
- 02Il traite le cycle de vie de l’application : mise en arrière-plan, reprise, perte de connexion, réinstallation.
- 03Il définit ce qui reste utilisable hors connexion et ce qui attend, et rend cette distinction visible à l’utilisateur.
- 04Il déclare chaque permission demandée, la raison de la demande, et le comportement de l’application si elle est refusée.
- 05Il mesure à chaque remise la taille du paquet installable et la consommation de données du parcours principal.
- 06Il gère la coexistence des versions : une ancienne version installée continue de fonctionner, ou dit clairement pourquoi elle ne le peut plus.
Ce qu’il ne fait jamais
- Il ne valide jamais son propre travail : un parcours qu’il exécute lui-même sur son appareil ne prouve rien pour l’appareil de l’utilisateur.
- Il ne valide jamais sur simulateur seul : un simulateur ne reproduit ni le réseau, ni la mémoire, ni la batterie.
- Il ne demande jamais une permission dont l’usage n’est pas écrit dans la spécification.
- Il ne conserve jamais un identifiant de session en clair sur l’appareil.
- Il ne suppose jamais la connexion disponible, ni au démarrage ni pendant un parcours.
- Reçoit de
- Responsable technique · Concepteur d’expérience
- Remet à
- Contrôle qualité
Ingénieur données
Il rend les données exploitables, traçables et récupérables, et il prouve la récupération au lieu de la promettre.
Ce qu’il fait, dans l’ordre
- 01Il établit le dictionnaire des données : pour chaque champ, sa signification, son format, son caractère obligatoire, sa source.
- 02Il déclare la donnée personnelle champ par champ et attache à chacune une durée de conservation.
- 03Il écrit les migrations dans un seul sens, numérotées et rejouables, avec la procédure de retour arrière de chacune.
- 04Il pose les contraintes d’intégrité dans la base plutôt que dans le code applicatif, chaque fois que la base sait les tenir.
- 05Il exécute au moins une fois la restauration d’une sauvegarde sur un environnement neuf, chronomètre l’opération, et publie le résultat.
- 06Il prépare un jeu de données de test réaliste et anonymisé, et le remet avec sa procédure de régénération.
Ce qu’il ne fait jamais
- Il ne copie jamais des données de production dans un environnement de développement ou de recette.
- Il ne considère jamais une sauvegarde comme valide tant qu’une restauration n’a pas été exécutée.
- Il ne modifie jamais une migration déjà appliquée : on en ajoute une nouvelle.
- Il ne laisse jamais un champ sans propriétaire déclaré ni durée de conservation.
- Reçoit de
- Architecte · Responsable technique
- Remet à
- Développeur serveur · Contrôle qualité
Ingénieur d’exploitation
Il rend la mise en service répétable par quelqu’un d’autre que lui, et le retour en arrière possible.
Ce qu’il fait, dans l’ordre
- 01Il sépare les environnements de développement, de recette et de production, et vérifie qu’aucun secret n’est partagé entre eux.
- 02Il installe la chaîne de vérification automatique et la rend bloquante à la fusion, puis provoque une fois son échec pour prouver qu’elle bloque.
- 03Il rend la mise en production reproductible par une seule séquence écrite, exécutable par une personne qui n’a pas écrit le code.
- 04Il écrit et exécute la procédure de retour arrière avant la première mise en production, jamais après.
- 05Il pose la surveillance : disponibilité, taux d’erreur, temps de réponse, et le seuil d’alerte de chacun.
- 06Il fixe la durée de conservation des journaux et vérifie qu’aucun secret ni donnée personnelle n’y figure.
- 07Il tient la liste nominative des accès en production et la révise à date fixe.
Ce qu’il ne fait jamais
- Il ne modifie jamais la production à la main : tout passe par la procédure écrite.
- Il ne met jamais en service sans procédure de retour arrière déjà exécutée hors production.
- Il ne donne jamais un accès de production à un agent automatique sans limite de portée écrite et durée déterminée.
- Il ne désactive jamais un contrôle bloquant pour livrer plus vite, même une seule fois.
- Reçoit de
- Architecte · Responsable technique · Responsable sécurité
- Remet à
- Contrôle qualité · Rédacteur technique · Chef de chantier
Responsable sécurité
Il cherche comment le système peut être détourné, et il exige la correction avant la mise en service.
Ce qu’il fait, dans l’ordre
- 01Il liste les biens à protéger : données personnelles, argent, accès, réputation, continuité de service.
- 02Il écrit le modèle de menaces : qui aurait intérêt à attaquer, par quelle porte, pour quel gain.
- 03Il éprouve l’authentification, la gestion des sessions et le contrôle des droits, en tentant l’accès à la ressource d’un autre compte.
- 04Il recherche les secrets présents dans l’historique complet du dépôt, et pas seulement dans la version courante.
- 05Il contrôle la surface exposée : points d’entrée publics, ports ouverts, dépendances et leurs vulnérabilités connues.
- 06Il classe chaque constat en bloquant, à corriger avant la prochaine version, ou accepté, et fait signer chaque acceptation par le chef de chantier.
- 07Il rejoue le constat après correction et ne le referme que sur exécution, jamais sur déclaration.
Ce qu’il ne fait jamais
- Il n’écrit jamais le correctif qu’il exige : celui qui répare ne peut pas être celui qui juge la réparation.
- Il ne clôt jamais un constat sur la parole de celui qui l’a corrigé.
- Il n’accepte jamais un risque à la place du chef de chantier : accepter un risque est une décision de direction, pas une décision technique.
- Il ne remplace jamais un contrôle manuel par la sortie d’un outil automatique sans l’avoir relue ligne à ligne.
- Reçoit de
- Architecte · Responsable technique
- Remet à
- Architecte · Responsable technique · Ingénieur d’exploitation · Chef de chantier
Contrôle qualité
Il exécute le plan de tests contre l’incrément livré et prononce conforme ou non conforme, sans troisième mention.
Ce qu’il fait, dans l’ordre
- 01Il écrit les cas de test à partir de la spécification, avant que l’incrément existe.
- 02Il écrit pour chaque exigence au moins un cas nominal, un cas limite et un cas d’erreur.
- 03Il installe l’incrément depuis le dépôt sur un environnement neuf, en suivant la documentation, et note chaque écart entre la procédure écrite et la réalité.
- 04Il exécute les cas dans l’ordre écrit et consigne le résultat observé, jamais le résultat attendu.
- 05Il rejoue les cas des incréments précédents pour détecter les régressions introduites.
- 06Il rédige chaque anomalie avec la version testée, les étapes de reproduction, le résultat observé et le résultat attendu.
- 07Il prononce conforme ou non conforme et remet le procès-verbal au chef de chantier.
Ce qu’il ne fait jamais
- Il n’écrit jamais le correctif de l’anomalie qu’il a relevée.
- Il ne teste jamais sur l’environnement du développeur, où tout est déjà configuré.
- Il ne modifie jamais un cas de test parce qu’il échoue.
- Il ne prononce jamais conforme avec réserve : une réserve est une non-conformité qui n’ose pas dire son nom.
- Il ne délègue jamais son jugement à une intelligence artificielle : un agent peut exécuter des cas, il ne prononce pas la recette.
- Reçoit de
- Responsable produit · Responsable technique · Développeur serveur · Développeur interface web · Développeur mobile · Ingénieur données · Ingénieur d’exploitation
- Remet à
- Responsable technique · Chef de chantier
Rédacteur technique
Il écrit ce qu’il faut savoir pour utiliser, exploiter et reprendre le système sans son auteur.
Ce qu’il fait, dans l’ordre
- 01Il écrit la procédure d’installation depuis un poste neuf, puis la fait exécuter par une personne qui n’a pas participé au développement.
- 02Il documente chaque variable de configuration : son rôle, sa valeur par défaut, la conséquence d’une valeur erronée.
- 03Il rédige le mode d’emploi des parcours utilisateurs principaux, avec des captures correspondant à la version livrée.
- 04Il tient le journal des versions : ce qui change, ce qui casse, ce qu’il faut faire pour migrer.
- 05Il consigne les décisions d’architecture dans un registre unique ordonné par date, jamais dispersé dans des messages.
- 06Il date chaque page et signale celles qui n’ont pas été revues depuis la dernière version livrée.
Ce qu’il ne fait jamais
- Il ne documente jamais une fonction qu’il n’a pas vue fonctionner.
- Il ne recopie jamais le code en prose : la documentation dit pourquoi, le code dit comment.
- Il ne laisse jamais une procédure publiée sans qu’un tiers l’ait exécutée au moins une fois.
- Il n’écrit jamais un secret ni une valeur réelle de production dans la documentation.
- Reçoit de
- Responsable technique · Ingénieur d’exploitation
- Remet à
- Chef de chantier