Une façon de diriger une entreprise dont une part croissante du travail est faite par des IA. Elle exige des choses de vous ; le logiciel se contente de les rendre bon marché.
Tant que produire coûtait cher, la ressource rare était la capacité à produire. C'est fini, et trois problèmes prennent sa place — dans cet ordre, dans toutes les entreprises qui mettent des IA au travail.
Aucun des trois n'est un problème technique. Les trois se répondent par ce qu'une équipe décide d'exiger d'elle-même.
Chaque chantier nomme l'objectif qu'il sert. Celui qui n'en nomme aucun ne démarre pas — et le dire à voix haute est votre travail, pas celui d'un outil.
Ce qui n'est rattaché à rien n'est jamais arbitré. Cela se fait parce que quelqu'un l'a demandé, et personne ne saura jamais si cela valait la peine.
Avant toute spécification technique, quelqu'un écrit le brief métier : pour qui, ce que cela change pour lui, et à quelle mesure on le saura. C'est celui qui porte l'objectif qui l'écrit — pas celui qui construira.
Un comment écrit sans pourquoi se construit exactement comme demandé, et ne sert à rien. Celui qui demande est le seul à pouvoir dire ce qui compterait comme une réussite.
La spécification énonce ce qui prouvera qu'elle est livrée — les pages à ouvrir, les chiffres à comparer, la réponse qui vaut « c'est fait » — avant que le travail commence.
Une recette écrite après coup est écrite pour être réussie. Écrite avant, elle est la définition du travail, et celui qui l'exécute sait exactement quand s'arrêter.
À la livraison, on nomme ce qu'il faudra revérifier et à quelle date. Une livraison sans date de revérification n'est pas finie, elle est abandonnée.
Ce qui a cessé de marcher sans bruit ne s'annonce pas. Sans date, on l'apprend d'un client — et c'est vrai depuis des mois.
Un résultat avance par une prise de parole datée, portant un chiffre et un niveau de confiance. « En risque » est une réponse autorisée, et attendue.
Un point qui ne dit jamais que « en bonne voie » ne porte aucune information. Le rituel ne vaut que parce qu'on peut y annoncer une mauvaise nouvelle.
Ce qu'on attend d'un agent existe par écrit, là où vit l'objectif — pas dans une conversation qui se ferme. Et l'agent rend compte au même endroit.
Une consigne qui vit dans une conversation meurt avec elle. Écrite, elle survit à la session, à la personne, et à l'outil qu'on utilisait cette semaine-là.
À la fin d'un chantier, ce qu'on a appris devient une règle que le chantier suivant lit. Pas une note dans un document de rétrospective que personne ne rouvre.
Les équipes n'oublient pas les leçons par négligence. Elles les oublient parce que la leçon a été rangée là où plus personne ne repasse.
Dans votre espace de travail, une page dit où en sont réellement vos pratiques — d'après ce qu'un agent a constaté de votre installation, jamais d'après une case cochée. Une auto-évaluation est une opinion ; cette page n'en affiche pas.
C'est la différence entre ce qu'on s'engage à pratiquer et ce qu'on pratique, et seule la seconde vaut d'être lue un mois difficile.
Tout ce qui précède est une discipline, pas une fonctionnalité. On peut tout pratiquer sans jamais ouvrir Galy, et certaines équipes le font.
Ce que fait Galy, c'est tenir toute la chaîne au même endroit — l'objectif, le brief, la spécification, la preuve, la date de revérification — pour que la tenir coûte moins cher que l'abandonner. C'est la seule chose qu'un outil puisse faire pour une méthode : la rendre assez bon marché pour survivre à un mois chargé.