Aller au contenu
NEXUS Academy

Filière métier

Directeur de chantier logiciel

Un directeur de chantier logiciel est une personne qui, sans écrire le code elle-même, comprend comment un logiciel est fait, connaît les procédures des développeurs professionnels, et dirige des agents d’intelligence artificielle pour construire des produits qu’elle sait vérifier.

Le directeur de chantier ne pose pas les briques. Il lit les plans, connaît les matériaux, sait dans quel ordre on bâtit, contrôle le travail, refuse ce qui est mal fait, et répond de l’ouvrage. Vous n’en sortirez pas développeur. Vous en sortirez capable de dire ce qu’il faut exiger, comment le vérifier, et quand dire non.

semaines
10
phases gouvernées
9
rôles nommés
14
gabarits
24

Trois blocs, 10 séances, un seul projet : le vôtre

Une séance par semaine, une mission par bloc. Chaque bloc se termine par une porte : votre livrable est contrôlé sur des critères que vous connaissez d’avance. On ne passe pas au suivant sur du non prouvé. C’est la méthode que vous apprendrez à imposer à vos agents, et vous la vivrez d’abord comme élève.

Bloc 1. Lire un système

3 semaines · semaines 1 à 3

Vous saurez ouvrir une application que vous n’avez pas construite et dire, par écrit, de quoi elle est faite, où vivent ses données et ce dont elle dépend sans le contrôler.

  1. S01

    Ce qu’est un logiciel, et s’il faut le construire

    Séparer la demande du besoin, éprouver un par un les sept seuils de non-construction, et écrire une note de cadrage qui conclut par construire, ne pas construire ou différer.

    Phases travaillées : Cadrage · 1 gabarit en main

  2. S02

    Les trois couches et le chemin d’une donnée

    Suivre une seule donnée depuis l’écran où elle est saisie jusqu’à l’endroit où elle est rangée, nommer chaque couche traversée, et distinguer ce qui a été constaté de ce qui a été supposé.

    Phases travaillées : Découverte · 1 gabarit en main

  3. S03

    Lire une pile technique, et ce dont elle dépend sans le contrôler

    Renseigner les neuf catégories techniques d’une application existante, y compris par « aucune » quand c’est la réponse, et nommer chaque dépendance externe avec l’effet observable de son arrêt.

    Phases travaillées : Découverte, Architecture · 2 gabarits en main

Mission : Carte d’une application réelle

Choisir une application en service que vous n’avez pas construite, et en produire la carte : ce qu’elle sert et à qui, le chemin complet d’une donnée depuis sa saisie jusqu’à son rangement, les neuf catégories techniques renseignées, et chaque dépendance externe avec l’effet de son arrêt. La carte est écrite pour quelqu’un qui ne connaît pas l’application : elle est jugée sur ce qu’un tiers peut en refaire, jamais sur ce que vous savez par ailleurs.

Porte B1

  • La note de cadrage conclut par l’une des trois décisions exactement : construire, ne pas construire, différer.
  • Les sept seuils de non-construction sont examinés un par un, et chacun porte la raison écrite pour laquelle il s’applique ou ne s’applique pas.
  • La carte nomme au moins une donnée et décrit son chemin complet, couche par couche, de la saisie jusqu’au rangement.
  • Les neuf catégories techniques sont renseignées ; aucune n’est laissée vide, et celles qui n’ont pas d’objet portent la mention « aucune » avec sa raison.
  • Chaque dépendance externe citée porte l’effet observable de son arrêt sur l’application.
  • Chaque affirmation qui n’a pas été constatée est marquée comme hypothèse et porte son moyen de vérification.
  • Le journal de direction est ouvert et porte au moins une entrée datée par semaine du bloc.

Si la porte refuse : On ne passe pas au bloc 2. La carte est renvoyée avec la liste des contrôles qui échouent, cités par leur libellé exact, et refaite sur la même application. Changer d’application pour éviter un contrôle qui échoue est précisément la faute que ce bloc enseigne à ne pas commettre : c’est ce qu’un agent fera plus tard si on le laisse choisir son propre terrain d’examen.

Bloc 2. Travailler comme un professionnel

3 semaines · semaines 4 à 6

Vous saurez équiper un chantier de sorte que la preuve se produise d’elle-même : un dépôt qui refuse ce qui n’est pas contrôlé, trois environnements qui ne partagent rien, et des pièces écrites qu’un agent ne peut pas interpréter de deux façons.

  1. S04

    Spécifier de sorte qu’il n’y ait qu’une lecture possible

    Écrire un parcours utilisateur pas à pas, les règles et les états qui le gouvernent, et l’écran qui le porte, puis relire chaque phrase en cherchant la seconde lecture qu’un agent pourrait en faire.

    Phases travaillées : Spécification · 3 gabarits en main

  2. S05

    Trancher l’architecture, puis équiper l’atelier

    Choisir entre deux options techniques sur des critères écrits avant de les comparer, consigner la décision avec son coût de sortie, puis monter le dépôt, les trois environnements et la chaîne de vérification bloquante.

    Phases travaillées : Architecture, Préparation du chantier · 3 gabarits en main

  3. S06

    Ce qu’un test prouve, et ce qu’il ne prouve pas

    Écrire le plan de tests depuis la spécification et avant tout code, provoquer une fois l’échec de la chaîne pour prouver qu’elle bloque, et distinguer le test qui décrit un comportement de celui qui décrit une implémentation.

    Phases travaillées : Préparation du chantier, Vérification · 2 gabarits en main

Mission : L’atelier, et les pièces écrites qui le rendent utile

Monter sur votre propre projet le dépôt dont la branche principale refuse l’écriture directe, les trois environnements sans aucun secret commun, et la chaîne de vérification rendue bloquante puis mise en échec une fois pour le prouver. Y déposer la spécification fonctionnelle, la maquette de l’écran principal, la décision d’architecture avec son coût de sortie, la spécification technique, le plan de tests daté d’avant tout code, et le plan de déploiement dont le retour arrière a été exécuté une fois hors production.

Porte B2

  • Une écriture directe sur la branche principale a été tentée et refusée par le dépôt lui-même, et le refus est joint au dossier.
  • La chaîne de vérification a été mise en échec une fois volontairement, elle a bloqué la fusion, et la date de cet échec est consignée.
  • Aucun secret ne figure dans l’historique du dépôt.
  • Les trois environnements existent et ne partagent aucun secret.
  • Le plan de tests porte une date antérieure à celle du premier code de l’incrément qu’il couvre.
  • La décision d’architecture nomme l’option écartée, la raison de l’écarter, et le coût de sortie de l’option retenue.
  • Le retour arrière du plan de déploiement a été exécuté une fois hors production, et sa date est consignée.
  • La spécification fonctionnelle décrit au moins un état d’erreur et ce que l’utilisateur voit alors.
  • La maquette de l’écran principal montre l’état vide, l’état chargé et l’état d’erreur, et chacun porte le texte réellement affiché.
  • La spécification technique nomme, pour chaque exigence fonctionnelle, le fichier ou le composant qui la portera.

Si la porte refuse : On ne passe pas au bloc 3. Ouvrir la construction sur un atelier incomplet revient à décider que la preuve sera produite plus tard, c’est-à-dire jamais : une chaîne rendue bloquante après le début du chantier ne bloque plus rien, puisqu’il faudrait alors refuser du travail déjà accepté. On finit l’équipement, quel que soit le calendrier annoncé.

Bloc 3. Diriger des agents

4 semaines · semaines 7 à 10

Vous saurez faire construire une fonctionnalité par un agent, incrément par incrément, refuser par écrit ce qui n’est pas démontré, et dire pourquoi la vérification ne se délègue jamais à une seconde intelligence artificielle.

  1. S07

    Briefer un agent comme un sous-traitant

    Employer les quatre parties d’un brief, dans l’ordre : le rôle et le mandat, le contexte factuel, la demande bornée avec son hors périmètre, le format de sortie exigé. Puis tenir le journal de direction le jour même, entrée par entrée.

    Phases travaillées : Construction · 2 gabarits en main

  2. S08

    Découper en incréments qui se prouvent un par un

    Commander une modification de comportement, une couche de données et un écran, en exigeant à chaque fois une démonstration qui tient sans le reste du produit et sans votre commentaire.

    Phases travaillées : Construction · 3 gabarits en main

  3. S09

    Refuser : le défaut, le périmètre gelé, la preuve insuffisante

    Exiger la reproduction d’un défaut avant sa correction, geler le périmètre d’un correctif, relever la sécurité d’un incrément, et écrire deux refus qui citent chacun le contrôle qui échoue par son libellé exact.

    Phases travaillées : Construction, Vérification · 5 gabarits en main

  4. S10

    La surface exposée, la mise en service, et l’ouvrage à tenir

    Relever la surface exposée de la fonctionnalité, écrire le plan de retour arrière, le carnet d’exploitation et le mode d’emploi de l’exploitant, puis prononcer la recette contre des critères écrits avant la construction.

    Phases travaillées : Vérification, Mise en service, Exploitation · 4 gabarits en main

Mission : Une fonctionnalité complète, construite sous votre direction

Faire construire par un agent, sur votre projet, une fonctionnalité entière découpée en au moins trois incréments démontrables seuls. Chaque incrément est commandé par un brief écrit, contrôlé contre le plan de tests du bloc 2, puis accepté ou refusé par écrit. Au moins un refus figure au dossier, motivé par le contrôle qui échoue et non par une impression. Le plan de mise en service et le carnet d’exploitation sont écrits et contrôlés ; leur exécution en production appartient à l’étage suivant.

Porte B3

  • La fonctionnalité est découpée en au moins trois incréments, et chacun a été démontré seul, sans le reste du produit.
  • Chaque incrément porte le brief qui l’a commandé, la preuve produite et la décision d’acceptation ou de refus, toutes trois datées.
  • Au moins un refus écrit figure au dossier, et il cite par son libellé exact le contrôle qui échoue.
  • Aucune vérification n’a été confiée à une seconde intelligence artificielle : le dossier nomme, pour chaque preuve, la personne qui l’a lue.
  • Le dossier de sécurité relève la surface exposée de la fonctionnalité, et chaque point relevé porte son sort : corrigé, accepté avec sa raison, ou reporté avec sa date.
  • Le procès-verbal de recette est daté, nomme qui a prononcé la recette, et reprend les critères contrôlés un par un.
  • Le carnet d’exploitation décrit la mise en service et son retour arrière en gestes qu’un tiers peut exécuter sans vous joindre.
  • Le journal de direction couvre les quatre semaines sans interruption et porte chaque refus.

Si la porte refuse : L’étage n’est pas franchi, et il ne se rattrape pas par un surcroît de travail sur la dernière semaine. On reprend au dernier incrément accepté, on cherche la phase qui a produit le défaut, et on y retourne. Un étage franchi sur un dossier incomplet ne vaudrait rien : ce que vous emportez de cette formation est précisément la preuve, et une preuve arrangée n’est plus une preuve.

Trois parcours, un seul processus

Un particulier, un salarié et une agence suivent les mêmes phases. Ce qui change, ce sont les artefacts contractuels, les personnes à consulter et le niveau de preuve exigé. Le processus ne se dilue pas selon le public : il s’épaissit.

Pour moi

Je construis mon propre produit, je suis mon seul client, et personne ne me demandera de comptes avant les utilisateurs.

Qui peut dire non :
Personne, sauf les fournisseurs dont les conditions encadrent l'activité, ce qui rend l'engagement écrit envers soi-même indispensable.
Variante de la mission finale :
Vous êtes seul, donc vous ne pouvez pas être à la fois celui qui commande et celui qui se contente du résultat : vous prononcez la recette à une date fixée avant la construction, contre les critères écrits avant elle, et vous nommez un témoin qui contresigne le procès-verbal.

Pour mon employeur

Je construis pour l'organisation qui m'emploie, il existe un commanditaire interne, et les règles de la maison s'appliquent avant les miennes.

Qui peut dire non :
Le commanditaire, le contrôle de gestion, la sécurité des systèmes, la protection des données, les achats et l'exploitation informatique.
Variante de la mission finale :
La recette est prononcée par le commanditaire interne ou par la personne qu’il désigne, jamais par vous seul. Le dossier de sécurité est remis à la personne qui répond de la sécurité, et son absence de réponse ne vaut pas accord.

Pour un client

Je construis pour une organisation qui n'est pas la mienne, un contrat nous lie, et chaque désaccord se règle sur pièces ou se paie.

Qui peut dire non :
Le signataire, le service juridique du client, sa sécurité, son futur exploitant, et votre assureur si le mandat sort de la couverture.
Variante de la mission finale :
La recette est contradictoire : le client dispose des critères avant la construction, il les emploie lui-même, et le procès-verbal porte sa signature et sa date. Ce qu’il refuse au titre de la garantie et ce qu’il commande en supplément sont séparés au moment de la recette, pas au moment de la facture.

Les quatre références du programme

Le programme n’est pas un catalogue d’astuces : c’est un processus écrit, opposable, que l’on consulte pendant le chantier et pas seulement pendant le cours.