Le Manuel de l’opérateur

Une personne, beaucoup de mains

Ce manuel s’adresse à un type de travailleur bien particulier : une personne seule, sans salariés, et une flotte d’agents d’IA qui feront avec entrain à peu près tout ce que vous leur demandez, à toute heure, en parallèle. Vous êtes peut-être indépendant, fondateur sans associé, consultant, écrivain doté d’une base de code, ou simplement quelqu’un qui a remarqué que le nombre de choses qu’il peut boucler dans une journée a cessé de dépendre de sa vitesse de frappe. Que le mot vous plaise ou non, vous êtes un opérateur.

Le mot compte, parce qu’il nomme le métier honnêtement. Vous n’êtes pas un manager, puisque personne sous vos ordres ne peut endosser la responsabilité de quoi que ce soit. Vous n’êtes plus tout à fait un artisan, puisque l’essentiel de la fabrication est assuré par autre chose que vous. Vous faites tourner une petite machine. Cette machine est faite d’agents, d’outils, de notes, d’une liste de projets et, surtout, de votre propre journée de travail. Quand elle tourne bien, une seule personne livre la production d’une petite équipe. Quand elle tourne mal, une seule personne passe la journée à superviser le chaos et se couche sans avoir rien terminé.

Ce qui sépare les deux, c’est rarement l’outillage. Tout le monde dispose à peu près des mêmes agents désormais. La différence tient au système d’exploitation : les habitudes qui décident de ce qu’on lance, de la façon dont on le décrit, dont on le vérifie, du moment où on le livre et de ce qu’on note ensuite. Ces habitudes sont le sujet de ce livre. Ce n’est pas un livre de business. Il ne vous dira pas quoi vendre ni à quel prix. Il parle de l’intérieur d’une journée de travail, celle d’une seule personne, et de la manière de lui faire produire des choses finies plutôt qu’une impression d’activité.

Les agents fournissent les mains. Vous fournissez l’ordre dans lequel elles bougent.

Le livre compte dix parties. Il commence par le métier lui-même, puis parcourt la journée d’exploitation, la rédaction des briefs, la mémoire et les notes, le registre des projets et la délégation des fils, la relecture du travail, la discipline de livraison, les boucles hebdomadaires et trimestrielles, l’entretien des outils et la gestion des erreurs. Il se termine là où tout ce qu’il contient converge : le vrai travail de l’opérateur, c’est de décider, pas de faire. Chaque chapitre enseigne une chose à essayer dès cette semaine. Aucun ne réclame de nouveau logiciel. La plupart demandent un fichier texte et un peu de cran.

Un mot sur le ton. Ces pages s’adressent à des gens déjà un peu las de s’entendre dire que tout a changé. Beaucoup de choses ont changé. Beaucoup d’autres non. Il faut toujours savoir ce qu’on cherche à obtenir, toujours vérifier qu’on l’a obtenu, et toujours s’arrêter de travailler à un moment donné pour dîner. Les agents rendent les deux premiers points plus importants, pas moins, et ils rendent le troisième plus facile à oublier.

Commencez donc ici, par un petit exercice. Notez, en une phrase chacune, les trois choses que vos agents ont faites pour vous la semaine dernière et que vous n’auriez pas faites vous-même. Puis notez la seule chose que vous avez faite et qu’aucun agent n’aurait pu faire. La seconde liste est plus courte. C’est aussi votre métier.

La journée est la machine

La plupart des gens qui font tourner des agents voient leur système comme un ensemble d’outils : cet assistant, ce terminal, ces connecteurs, ces scripts. Les outils comptent, mais ils ne sont pas la machine. La machine, c’est votre journée de travail. C’est l’ordre dans lequel les choses se produisent entre le réveil et l’arrêt, et c’est lui qui détermine vers quoi les outils sont pointés. Deux opérateurs aux outils identiques et aux journées différentes produiront des semaines radicalement différentes.

Pensez la journée en trois temps. Le matin, vous faites la revue : vous lisez ce qui s’est passé pendant votre absence, vous décidez de ce qui compte maintenant, et vous choisissez un petit nombre de résultats pour la journée. Au milieu, vous menez des sessions : des plages de temps bornées pendant lesquelles vous briefez des agents, suivez leur travail, relisez ce qui revient, puis le livrez ou le renvoyez pour un tour de plus. À la fin, vous clôturez : vous notez ce qui est fini, ce qui ne l’est pas et ce par quoi demain devrait commencer, puis vous vous arrêtez. Revue, sessions, clôture. Tout le reste de la journée d’exploitation n’est qu’une variation sur cet arc.

Cela paraît évident, et ça l’est, ce qui explique pourquoi si peu de gens le font vraiment. La journée par défaut d’un opérateur équipé d’agents est réactive. Vous ouvrez l’ordinateur, remarquez qu’une tâche de fond s’est terminée, la lisez, corrigez un détail, ouvrez un nouveau fil parce qu’une idée vous est venue, répondez à un message, jetez un œil à un autre fil, et levez la tête pour découvrir qu’il est seize heures, que vous avez touché à onze choses et n’en avez fini aucune. Les agents aggravent la situation, car chacun génère davantage de matière à regarder. La machine sans forme devient une machine à produire des notifications.

Une journée sans forme prend la forme de ce qui crie le plus fort.

Le remède consiste à traiter la forme de la journée comme une décision de conception plutôt que comme un accident. Décidez quand a lieu la revue et combien de temps elle dure. Décidez combien de sessions la journée peut contenir et quelle taille elles ont à peu près. Décidez quand a lieu la clôture et ce qu’elle produit. Écrivez tout cela quelque part où vous le verrez. Ce sera faux au début, et vous ajusterez, mais un plan faux qu’on peut ajuster vaut mieux que pas de plan du tout, parce que sans plan il n’y a rien à ajuster.

Il est utile de remarquer que les agents ne se fatiguent pas, et vous si. La machine peut tourner toute la nuit ; l’opérateur, non. La journée est donc la partie du système qui a des limites dures, et c’est sur les limites dures que la conception paie. Un concepteur de bases de données s’inquiète de la requête la plus lente. Un opérateur devrait s’inquiéter de l’heure la plus rare, qui est généralement la première bonne heure de la matinée, et la consacrer à décider plutôt qu’à bricoler.

Essayez cette semaine. Pendant cinq jours ouvrés, notez trois heures sur une fiche : la fin de la revue, la fin de la dernière session et le moment de la clôture. N’essayez de rien améliorer. Regardez, simplement. La plupart des gens découvrent que la clôture n’a jamais lieu, et que la revue se fond discrètement dans la première session. Ce n’est pas une faute morale. C’est une machine à laquelle il manque une pièce. Posez la pièce.

Faire ou décider

Pendant la plus grande partie de l’histoire du travail, faire et décider allaient de pair. Si vous vouliez un rapport, vous décidiez de ce qu’il devait dire, puis vous l’écriviez, et l’écriture prenait tant de temps qu’elle avait l’air d’être le vrai travail. La décision se cachait dans l’exécution. Vous choisissiez la structure en rédigeant le premier paragraphe, changiez d’avis sur la conclusion à mi-chemin, et le rapport fini était la trace de toutes ces petites décisions.

Les agents dissocient les deux. Le faire, qui prenait des heures, prend désormais des minutes et peut se passer de vous. Le décider ne rétrécit pas du tout. Il grossit plutôt, parce que l’agent fera exactement ce que vous avez décidé, et que si vous avez décidé vaguement, vous obtenez très vite un résultat vague. La journée de l’opérateur bascule donc. On en passe moins à fabriquer. On en passe davantage à choisir quoi fabriquer, à le décrire précisément, à juger ce qui revient, et à choisir de nouveau.

C’est inconfortable pour quiconque a bâti son identité sur le faire. Fabriquer procure une satisfaction que décider procure rarement. On peut montrer une page qu’on a écrite ou une fonctionnalité qu’on a construite. Il est plus difficile de montrer une bonne décision, car les bonnes décisions ressemblent surtout à rien du tout : un projet pas lancé, une fonctionnalité pas ajoutée, une mauvaise pull request pas fusionnée. Quand les agents vous retirent le faire, la tentation est d’en reprendre un peu pour le réconfort : réécrire avec vos mots le brouillon de l’agent alors qu’il était très bien, ou corriger le bug vous-même parce qu’attendre vous donnait l’impression de ne servir à rien.

Résistez à la tentation, mais sans dogmatisme. Il existe un test simple pour tout travail posé devant vous : faut-il que ce soit moi, précisément, qui le fasse ? Certaines choses, oui. Une conversation avec quelqu’un qui vous fait confiance. Un jugement de qualité que vous seul pouvez porter. Un texte dont toute la valeur tient à ce qu’il est de vous. Tout le reste est candidat à la délégation, et la question devient alors comment bien le briefer, plutôt que de savoir s’il faut le faire soi-même.

Faire donne l’impression d’avancer. Décider, c’est avancer.

Notez aussi que décider n’est pas la même chose que réfléchir à quelque chose. Un opérateur peut perdre des matinées entières en délibérations qui n’atterrissent jamais. Une décision est une phrase qui contient un verbe : nous livrerons la petite version jeudi ; nous abandonnons la deuxième fonctionnalité ; nous réécrivons le brief et le relançons. Si votre réflexion ne se termine pas par une phrase de ce genre, ce n’était pas une décision. C’était de la météo.

Cette semaine, donc, tenez un décompte. Chaque fois que vous vous asseyez pour faire vous-même un travail, posez d’abord la question du test et notez de quel côté elle est tombée. Ne changez pas votre comportement ; comptez, c’est tout. Vendredi, vous saurez quelle fraction de votre journée relève d’un faire que vous seul pouvez assurer, et quelle fraction relève d’un faire que vous n’avez pas encore appris à confier. Le second chiffre mesure votre marge de progression. Il est généralement plus grand que vous ne l’espériez, et aussi plus grand que vous ne le craigniez.

Les trois questions de l’opérateur

Tout travail qu’un opérateur lance devrait survivre à trois questions. Que voulons-nous ? Pourquoi maintenant ? Comment saurai-je ? Y répondre prend environ une minute, et c’est la minute la mieux employée de la journée, car le travail qui échoue à ces questions a tendance à dévorer des heures avant que quiconque remarque qu’il n’a jamais valu la peine.

La première question, que voulons-nous, semble triviale et ne l’est pas. La plupart des exécutions d’agents ratées échouent ici. L’opérateur avait une intuition, l’a tapée dans un prompt, et a reçu quelque chose qui correspondait aux mots mais pas à l’intuition. Le remède consiste à répondre en termes de résultat plutôt que d’activité. Non pas regarder le parcours d’inscription, mais un nouvel utilisateur peut s’inscrire et atteindre son premier élément enregistré sans aide. Une activité peut se poursuivre indéfiniment. Un résultat existe ou n’existe pas.

La deuxième question, pourquoi maintenant, est la défense de l’opérateur contre l’infini. Les agents rendent le lancement des choses bon marché, ce qui signifie que la réserve d’idées plausibles grossit plus vite qu’aucun humain ne peut en relire la production. Pourquoi maintenant vous oblige à classer. Peut-être quelque chose est-il cassé et vous coûte-t-il tous les jours. Peut-être une porte se fermera-t-elle la semaine prochaine. Peut-être est-ce simplement la chose la plus utile de la liste. Toutes ces réponses conviennent. Parce que j’y ai pensé ce matin ne convient pas, bien que ce soit la plus fréquente.

La troisième question, comment saurai-je, est celle qui rend la délégation possible. Si vous ne pouvez pas dire à quoi vous reconnaîtriez la réussite, vous ne pouvez pas demander à un agent de l’atteindre, et encore moins vérifier s’il l’a atteinte. Une bonne réponse nomme une vérification : les tests passent et le nouveau échoue sans la modification ; la page se charge sur un téléphone ; le résumé tient sur un écran et mentionne les quatre fournisseurs. Une mauvaise réponse, c’est je le saurai quand je le verrai, ce qui veut dire que vous verrez quelque chose et que vous vous disputerez ensuite avec vous-même à son sujet.

Si vous ne savez pas dire comment vous saurez, vous n’êtes pas prêt à demander.

Les questions se resserrent à mesure qu’on avance, et c’est pourquoi il vaut la peine de les poser dans l’ordre. La première est large et généreuse ; elle laisse entrer tout ce que vous pourriez vouloir. La deuxième filtre selon le moment et le coût. La troisième ne garde que le travail que vous pouvez réellement vérifier. Ce qui ressort en bas est petit, précis et vérifiable, soit exactement la forme que les agents gèrent le mieux et que les opérateurs relisent le plus vite.

Pas besoin de formulaire pour cela. Une ligne en tête de chaque brief suffit. Certains opérateurs écrivent les trois réponses comme les trois premières phrases de chaque tâche, avant toute instruction. Cela paraît un peu cérémonieux au début. Au bout de quinze jours, on ne le remarque plus, et l’on remarque en revanche combien on jette moins de travail. Les questions ne vous rendent pas plus intelligent. Elles vous empêchent simplement d’être occupé à la mauvaise chose, ce qui, dans une journée pleine d’agents zélés, constitue l’essentiel de la bataille.

Le débit n’est pas le but

La première chose que vous donnent les agents, c’est du volume. Demandez dix variantes, vous en obtenez dix. Demandez une fonctionnalité, vous obtenez la fonctionnalité, ses tests, une migration et un résumé bien rangé. Lancez cinq fils avant le déjeuner et vous aurez cinq lots de résultats à l’heure du goûter. C’est grisant, et comme la plupart des choses grisantes, c’est un piètre indicateur de vos progrès réels.

La production, c’est ce que fabrique la machine. Le résultat, c’est ce qui change dans le monde grâce à elle. Un opérateur peut générer une production énorme sans le moindre résultat : des brouillons jamais publiés, des branches jamais fusionnées, des prototypes jamais montrés à personne. Le tableau de bord a l’air chargé, le travail a l’air impressionnant, et rien n’a bougé. C’est le piège de l’agitation, et les agents le creusent encore, car le coût de produire une chose de plus est tombé presque à zéro tandis que le coût d’en finir une de plus n’a pas baissé du tout.

Finir coûte cher parce que cela vous implique. Quelqu’un doit relire le travail, décider qu’il est assez bon, le pousser dans le monde et gérer ce qui arrive ensuite. Chacune de ces étapes puise dans votre attention, qui est fixe. Un opérateur qui lance plus qu’il ne peut finir n’augmente donc pas son débit. Il construit une file d’attente, et les files d’attente ont la fâcheuse habitude de se transformer en culpabilité.

Commencé est un coût. Fini est un résultat.

Il est utile de représenter son travail sur deux axes. L’un est la production : combien a été fabriqué. L’autre est le résultat : quelle part en a atteint quelqu’un et a fait une différence. La plupart des opérateurs, quand ils découvrent les agents, glissent le long de l’axe de la production et restent bas sur celui du résultat. Le quadrant qu’on vise est celui où la production est modeste et le résultat élevé : moins de choses, finies. Cela paraît moins productif. C’est immensément plus productif, comme peut en témoigner quiconque a déjà livré une chose au lieu d’en commencer quatre.

L’habitude pratique consiste à mesurer ce qu’on finit plutôt que ce qu’on commence. À la fin de chaque journée, ne comptez que ce qui a franchi la ligne : fusionné, publié, envoyé, livré, décidé. Ne comptez ni les fils ouverts ni les brouillons créés. Si le compte est à zéro, c’est une information, pas un reproche. Cherchez pourquoi. En général, la réponse est que trop de choses ont été lancées et qu’aucune n’a reçu l’attention de relecture nécessaire pour être finie.

Il y a un bénéfice secondaire. Quand vous comptez ce que vous finissez, vous commencez à briefer autrement. Vous cessez de demander aux agents une exploration tentaculaire et commencez à demander la plus petite chose qui puisse être finie aujourd’hui. Vous découpez les gros chantiers en morceaux qui peuvent chacun être livrés seuls. Vous remarquez qu’une grosse chose à moitié finie vaut moins qu’une petite chose finie, parce que la petite peut servir et que la grosse ne peut qu’être admirée.

Essayez pendant une semaine : un seul chiffre sur une fiche, le nombre de choses finies par jour. Ignorez tout ce que la machine vous raconte d’autre sur son niveau d’activité. La machine est toujours occupée. C’est sa nature. La vôtre est de décider quelle part de cette agitation devient réelle.

Direct, sans préambule

Les agents n’ont pas besoin qu’on les échauffe. Ils n’ont pas besoin qu’on leur dise qu’on espère qu’ils vont bien, que la demande est un peu étrange, ou qu’on réfléchit à quelque chose depuis un moment. Ils ont besoin de savoir ce que vous voulez, ce qu’ils doivent savoir pour le faire, et comment vous jugerez le résultat. Tout le reste est préambule, et le préambule coûte plus cher qu’il n’en a l’air.

Il coûte, d’abord, en clarté. Un brief qui s’ouvre sur trois phrases de mise en contexte rend l’instruction véritable plus difficile à trouver, pour l’agent comme pour vous quand vous le relirez plus tard. Les agents accordent du poids à tout ce qu’on place devant eux, si bien qu’une ouverture sinueuse peut faire dériver le travail dans des directions que vous n’aviez pas prévues. Si vous mentionnez en passant que la performance vous inquiète, ne soyez pas surpris de voir une simple modification de texte arriver emballée dans une couche de cache.

Il coûte, ensuite, en clarté de votre propre pensée. Le préambule, c’est souvent ce qu’on écrit pendant qu’on cherche encore ce qu’on veut. C’est très bien de le faire, mais faites-le dans un carnet, pas dans le brief. Écrivez librement, puis supprimez tout ce qui précède la première phrase contenant un verbe et un résultat. Ce qui reste est généralement le brief que vous vouliez écrire.

Dites la chose. Puis dites comment vous saurez qu’elle est faite. Puis arrêtez-vous.

La même règle vaut dans l’autre sens. Demandez aux agents d’être directs avec vous. Un bon compte rendu commence par le résultat et la preuve, pas par le récit du voyage. Fait : l’importateur gère désormais les lignes vides ; le nouveau test échoue sur l’ancien code et passe sur le nouveau ; suite complète au vert vaut plus que trois paragraphes décrivant l’enquête. Vous pouvez toujours demander l’histoire. Vous ne devriez pas avoir à creuser pour trouver le verdict.

Il ne s’agit pas d’être sec. Il s’agit de respecter la ressource la plus rare du système, votre attention. Chaque phrase inutile qu’écrit un agent est une phrase qu’il vous faut lire avant de décider de la suite. Multipliez par vingt fils par jour, et le préambule devient un impôt sur toute votre activité. Beaucoup d’opérateurs placent une consigne permanente en ce sens dans la mémoire de leur projet : commence par le résultat, puis la preuve, puis les questions ouvertes, et garde le résumé court. C’est l’une des lignes les plus rentables que vous puissiez écrire.

La franchise rend aussi le désaccord moins coûteux. Si un agent pense que votre approche est mauvaise, vous voulez qu’il le dise dès la première ligne, pas qu’il enfouisse son objection au quatrième paragraphe après avoir fait le travail quand même. Demandez-le explicitement. Le parler franc dans les deux sens transforme la collaboration : on passe d’un échange poli de documents à quelque chose qui ressemble davantage à une vraie conversation de travail.

Cette semaine, reprenez donc vos dix derniers briefs et supprimez la première phrase de chacun. Puis voyez si le brief tient encore debout. Dans la plupart des cas, il sera plus clair. Le préambule était pour vous. L’agent n’en a jamais eu besoin, et, à bien y réfléchir, vous non plus.

Agir vite, preuves à l’appui

Les opérateurs qui réussissent avec les agents partagent souvent un tempérament : ils préfèrent essayer quelque chose plutôt que d’en discuter. Quand surgit une question qu’une expérience pourrait trancher, ils lancent l’expérience. Quand il faut un brouillon, ils en font faire un, puis se disputent avec le brouillon plutôt qu’avec une page blanche. Les agents récompensent généreusement ce tempérament, car des expériences qui prenaient une journée prennent désormais dix minutes, et il n’y a plus guère d’excuse pour délibérer longuement sur des choses qu’on pourrait simplement tester.

Mais le goût de l’action a son mode de défaillance, et les agents le récompensent aussi. L’opérateur qui agit vite sans vérifier se retrouve avec une foule de choses qui ont l’air faites et ne le sont pas. Une migration qui a tourné mais a discrètement sauté des enregistrements. Une page superbe sur un ordinateur portable qui s’effondre sur un téléphone. Un résumé assuré et faux. Chacune est bon marché à produire et coûteuse à découvrir plus tard, généralement au pire moment et souvent par quelqu’un d’autre.

La réponse n’est pas de ralentir. C’est d’attacher votre vitesse à des preuves. Agissez aussi vite que vous voulez, à condition que chaque action produise quelque chose de vérifiable, et que vous le vérifiiez effectivement avant de bâtir dessus. Voilà l’intersection qui compte : ni la prudence, ni la précipitation, mais des gestes rapides qui laissent chacun derrière eux une preuve. L’opérateur vit dans cette intersection.

Allez aussi vite que vos preuves peuvent suivre.

En pratique, cela signifie intégrer la vérification à l’action. Quand vous briefez un agent, incluez l’étape de contrôle : lancer les tests, charger la page, compter les lignes avant et après, comparer le résumé à la source. Quand vous agissez vous-même, décidez à l’avance de ce que vous regarderez ensuite. S’il n’y a rien à regarder, trouvez quelque chose, ou reconnaissez que vous devinez et traitez le résultat comme provisoire.

Cela signifie aussi être honnête sur ce qui est réversible. Essayer une nouvelle mise en page sur une branche s’annule facilement ; agissez librement. Envoyer un e-mail à toute une liste ne s’annule pas ; ralentissez et regardez à deux fois. Une habitude utile consiste à étiqueter chaque action, en silence, comme esquisse ou comme engagement. Les esquisses peuvent être rapides et brouillonnes. Les engagements exigent des preuves. La plupart des ennuis des opérateurs viennent de ce qu’ils ont traité un engagement comme une esquisse, parce que l’agent avait rendu la chose si facile.

Cette façon de travailler procure un plaisir qu’on remarque mal. Quand chaque geste laisse une preuve, vous cessez de porter l’angoisse de savoir si les choses sont vraiment faites. Vous le savez, parce que vous avez regardé. Cela libère de l’attention pour la décision suivante, ce qui à son tour vous rend plus rapide. La preuve n’est pas un frein au goût de l’action. C’est ce qui vous permet de garder le pied au plancher.

Cette semaine, choisissez une tâche sur laquelle vous auriez d’ordinaire délibéré, et menez-la plutôt comme une expérience. Avant de commencer, écrivez la vérification unique qui vous dirait que ça a marché. Puis faites-la, vérifiez, et regardez combien de temps tout cela a pris. Ce sera moins long que ne l’aurait été la délibération.

L’artefact d’abord

Il existe une règle simple qui fait gagner aux opérateurs un temps remarquable : dans le doute, fabriquez la chose. Ne décrivez pas le tableau de bord ; faites-en construire un, sommaire. Ne débattez pas de la structure du rapport ; faites rédiger un brouillon selon deux structures et lisez les deux. N’imaginez pas l’effet que produira l’e-mail de bienvenue ; produisez-le et lisez-le comme si vous l’aviez reçu. Un artefact posé sur la table met fin à plus de débats que n’importe quelle discussion à son sujet.

C’était autrefois un conseil coûteux. Fabriquer un prototype prenait des jours, si bien qu’il était raisonnable d’en parler d’abord et de ne construire qu’une fois à peu près sûr de soi. Les agents ont inversé l’économie de la chose. Une version sommaire de presque n’importe quoi coûte désormais moins cher que la réunion que vous auriez tenue à son sujet, même si cette réunion n’avait lieu qu’avec vous-même. L’ordre des opérations change donc. Au lieu de réfléchir, décider, construire, on passe à construire grossièrement, regarder, décider, construire proprement.

Si cela fonctionne, c’est que les gens, vous compris, sont bien meilleurs pour réagir que pour imaginer. Devant une page, vous savez en quelques secondes que le titre est trop long et que le bouton est mal placé. Invité à imaginer la page, vous pouvez y passer une heure et rater les deux. Un artefact convertit des préférences vagues en objections précises, et les objections précises sont des choses sur lesquelles un agent peut agir.

On ne peut pas relire une intention. On peut relire un artefact.

Deux disciplines empêchent l’artefact d’abord de dégénérer en prolifération d’artefacts. La première est d’étiqueter honnêtement l’artefact. Une esquisse est une esquisse. Dites à l’agent que c’est une esquisse, pour qu’il ne s’épuise pas en finitions, et dites-vous que c’est une esquisse, pour ne pas en tomber amoureux. Beaucoup d’opérateurs gardent un dossier ou une branche à part pour les artefacts jetables, précisément pour que rien de ce qui s’y trouve ne puisse être pris pour du vrai travail.

La seconde discipline est de conclure chaque artefact par une décision. Le but de la fabrication était d’apprendre quelque chose. Une fois que vous l’avez regardé, notez ce que vous avez appris et ce que vous allez faire : garder cette direction, l’abandonner, ou changer une chose précise et regarder de nouveau. Un artefact qui ne débouche pas sur une décision n’est que de la production, et les chapitres précédents ont été clairs sur ce que vaut la production seule.

L’artefact d’abord améliore aussi vos briefs. Quand vous avez une version sommaire sous les yeux, le brief suivant peut la désigner : garde la mise en page, change le ton du texte, rends le tableau triable. Désigner est bien plus précis que décrire. Le premier artefact vaut souvent moins pour lui-même que pour le vocabulaire qu’il vous donne pour demander le second.

Cette semaine, trouvez une décision que vous repoussez parce que vous n’arriviez pas à vous représenter les options. Demandez à un agent deux versions sommaires, côte à côte, sous la forme que la chose prendra au bout du compte. Accordez-vous dix minutes pour les regarder. Remarquez avec quelle rapidité la décision se prend toute seule dès qu’il y a quelque chose à regarder. Il lui fallait simplement un visage.

La règle de la petite machine

Tout opérateur finit par construire trop de machine. Cela commence innocemment. Vous écrivez un script pratique, puis un modèle, puis un jeu d’instructions pour une tâche récurrente, puis un tableau de bord pour suivre les tâches récurrentes, puis un agent pour mettre à jour le tableau de bord. Chaque pièce a du sens isolément. Ensemble, elles forment un système qui réclame sa propre maintenance, sa propre documentation et, bientôt, son propre opérateur. Vous vouliez faire tourner une petite entreprise et vous découvrez que vous dirigez un petit éditeur de logiciels dont l’unique client est vous-même.

La règle de la petite machine est une défense contre cela. Elle dit : gardez le système entier assez petit pour pouvoir le tenir dans votre tête un mauvais jour. Pas un bon jour, quand vous êtes reposé, curieux et content de bricoler, mais un jeudi après-midi fatigué, quand quelque chose a cassé et qu’il faut savoir où regarder. Si vous ne pouvez pas esquisser votre système de mémoire au dos d’une enveloppe, il est trop gros.

Que contient une petite machine ? Généralement bien moins qu’on ne l’imagine. Un registre des projets, pour savoir ce qui est en cours. Une poignée de recettes réutilisables pour le travail que vous faites régulièrement. Un petit ensemble stable d’outils que vous connaissez bien. Et, tout en bas, un rythme quotidien unique qui vous dit quand faire la revue, quand travailler et quand vous arrêter. Ce rythme est la fondation ; le reste repose dessus. Un opérateur doté d’un bon rythme et de trois outils fera mieux qu’un autre doté d’un mauvais rythme et de trente.

S’il vous faut un mode d’emploi pour votre mode d’emploi, arrêtez de construire.

La règle va à l’encontre d’un instinct naturel. Les agents rendent la fabrication d’outils si facile qu’il peut sembler irresponsable de ne pas automatiser chaque étape répétée. Mais l’automatisation a un coût de possession. Chaque script doit continuer de fonctionner à mesure que le monde autour de lui change. Chaque modèle se périme. Chaque service connecté exige qu’on revoie ses autorisations et qu’on remarque ses pannes. Le coût est faible pour chacun et lourd au total, et il se paie précisément dans la monnaie qui vous manque le plus : l’attention.

Avant d’ajouter une pièce à la machine, posez donc deux questions. Est-ce que je m’en servirai au moins une fois par semaine ? Et est-ce que je remarquerai quand elle casse ? Si la réponse à l’une des deux est non, faites la tâche à la main ou par un brief ponctuel, et attendez que le motif fasse ses preuves. Une recette exécutée cinq fois à la main est prête à être écrite. Une recette exécutée une fois est une supposition.

Il est tout aussi utile de soustraire. Une fois par trimestre, listez chaque élément de votre système et demandez-vous lesquels vous n’avez pas utilisés depuis un mois. Supprimez-les, ou au moins rangez-les hors de vue. Les opérateurs regrettent rarement une suppression. Ils regrettent souvent l’heure passée à déboguer une automatisation astucieuse qui leur faisait gagner quatre minutes par semaine.

Cette semaine, dessinez votre machine. Une page, de mémoire. Ce que vous oubliez d’y mettre est candidat à la suppression. Ce que vous ne pouvez pas expliquer en une phrase est candidat à la simplification. La machine que vous savez dessiner est la machine que vous savez faire tourner.

Le nom sur la porte

Il y a un fait du métier d’opérateur qui ne change pas, quelle que soit la compétence des agents : c’est votre nom qui est sur la porte. Quand quelque chose est livré, c’est livré en votre nom. Quand ça casse, ça casse en votre nom. Un client, un lecteur ou un utilisateur ne demandera jamais quel agent a écrit le paragraphe ni quel fil a produit le bug. Il vous le demandera à vous, et il aura raison.

Ce n’est pas un fardeau dont il faut se plaindre. C’est ce qui fait du métier un métier. Si les agents pouvaient répondre des résultats, ils n’auraient pas besoin d’opérateur, et tout l’arrangement serait plus simple et nettement moins intéressant pour vous. La responsabilité est ce qui transforme un tas d’outils compétents en une activité qui fonctionne. Il faut bien que quelqu’un décide de ce que veut dire « assez bon », et que quelqu’un en réponde ensuite.

Ce qui découle de la responsabilité est surtout affaire d’attention. Les agents font le travail, largement et vite. Vous relisez le travail, étroitement et soigneusement, parce que c’est dans la relecture que votre responsabilité devient réelle. Et vous assumez le résultat, ce qui signifie que la relecture doit être assez bonne pour que vous soyez à l’aise de le défendre devant quelqu’un qui compte. Cette progression se resserre à mesure : beaucoup de travail, moins de relecture, un seul responsable. Le resserrement est tout l’intérêt.

On peut déléguer l’effort. On ne peut pas déléguer les excuses.

La responsabilité façonne aussi les briefs que vous écrivez. Un opérateur qui sait qu’il répondra du résultat écrit des contraintes plus claires, exige des preuves plus solides et se laisse moins tenter de tout valider un vendredi après-midi. C’est une expérience de pensée utile, avant d’approuver quoi que ce soit, que d’imaginer l’expliquer à la personne la plus concernée. Si l’explication commence par eh bien, c’est l’agent qui a décidé, vous n’avez pas fini de relire.

Rien de tout cela ne veut dire tout faire soi-même par anxiété. C’est l’échec inverse, et il est tout aussi répandu chez les gens consciencieux. La responsabilité est compatible avec une délégation massive, à condition que ce que vous déléguez revienne par un point de contrôle que vous maîtrisez. Un bon rédacteur en chef répond de son magazine sans en écrire chaque article. Un bon capitaine répond de son navire sans serrer chaque boulon. Tout l’art consiste à placer les points de contrôle là où ils attraperont ce qui compte, et c’est le sujet de la plus grande partie de ce livre.

Il y a aussi un bénéfice plus discret. Assumer le résultat donne au travail un centre de gravité. Quand vous jonglez avec une douzaine de fils et une flotte d’agents, il est facile d’avoir l’impression que le travail vous arrive plutôt qu’il ne passe par vous. Se rappeler qu’on va le signer ramène dans le fauteuil de l’opérateur. Vous cessez de regarder la machine et commencez à la piloter.

Cette semaine, donc, avant d’approuver tout ce qui sera vu par une autre personne, marquez une pause de cinq secondes et demandez-vous : est-ce que je signerais ceci ? Pas est-ce que c’est probablement bon, mais est-ce que j’y mettrais mon nom. La plupart du temps, la réponse sera oui. Les rares fois où ce ne sera pas le cas seront les cinq secondes les plus précieuses de votre semaine.

La forme d’une bonne journée

Une bonne journée d’exploitation a une forme qu’on pourrait dessiner en trois traits. Un court moment de revue au début, un long milieu fait de sessions, et une courte clôture à la fin. Les détails varient selon la personne, la saison et la quantité de café disponible à la maison, mais la forme tient. Quand des opérateurs décrivent une journée réussie, ils décrivent presque toujours cette forme. Quand ils décrivent une journée ratée, ils décrivent généralement son absence.

La revue vient en premier parce que c’est là que se décide la journée. Vous lisez ce qui s’est passé depuis votre dernier coup d’œil, séparez ce qui demande votre jugement de ce qui n’en demande pas, et choisissez un petit nombre de résultats pour aujourd’hui. C’est le moment de la journée qui offre le plus grand effet de levier pour le moins de drame. Rien ne se construit pendant la revue. Tout ce qui se construit ensuite en dépend.

Les sessions remplissent le milieu. Une session est une plage de travail bornée, tournée vers un seul résultat : vous briefez, les agents travaillent, vous relisez, vous livrez ou vous renvoyez. La journée peut contenir deux sessions ou six, selon leur taille et selon vous. Ce qui compte, c’est que chacune ait un début et une fin, pour que le milieu de la journée soit une suite de tentatives achevées plutôt qu’une longue traînée d’attention partielle.

La clôture vient en dernier parce que c’est elle qui rend possible la revue du lendemain. Vous notez ce qui a été livré, ce qui reste ouvert et ce que devrait être le premier geste de demain. Puis vous vous arrêtez, au sens plein du terme : fils mis en pause ou laissés tourner exprès, ordinateur fermé, attention rendue à tout ce que contient le reste de votre vie. La clôture est la partie que la plupart des opérateurs sautent, et son absence explique pourquoi tant de matinées commencent par vingt minutes passées à essayer de se rappeler où en étaient les choses.

Commencez exprès, finissez exprès, et le milieu se débrouillera presque tout seul.

Pourquoi une forme si simple fonctionne-t-elle si bien ? Parce qu’elle sépare deux modes de pensée qui se gênent mutuellement. La revue et la clôture servent à décider : ce qui compte, ce qui est fini, ce qui vient ensuite. Les sessions servent à diriger et à juger un travail précis. Quand les modes se brouillent, la décision se prend mal, dans les interstices entre deux tâches, et les tâches sont interrompues par des décisions à moitié prises. Donner à chaque mode son propre temps protège les deux.

La forme vous donne aussi un endroit où ranger ce qui ne rentre nulle part. Une idée nouvelle au milieu d’une session va sur une liste pour la revue du lendemain, au lieu de devenir un nouveau fil. Une inquiétude en fin de journée va dans les notes de clôture plutôt que dans votre soirée. La forme est un ensemble de contenants, et ce sont les contenants qui empêchent un système chargé de déborder.

Cette semaine, n’essayez pas de perfectionner la journée. Posez simplement les trois traits dans votre agenda : un bloc de revue, un bloc de clôture, et tout ce qui se trouve entre les deux étiqueté « sessions ». Gardez la revue et la clôture courtes ; vingt minutes chacune suffisent largement pour commencer. Voyez ce qui arrive au milieu quand ses bords sont fermes. La plupart des gens constatent qu’il se tient mieux. Les milieux se tiennent généralement mieux, une fois que quelqu’un a tracé les bords.

La revue du matin

La revue du matin, ce sont les vingt minutes qui décident si le reste de la journée mènera quelque part. Ce n’est pas du rattrapage. Ce n’est pas la consultation des messages. C’est un petit acte de tri structuré, qui prend tout ce qui s’est accumulé depuis la clôture de la veille et le réduit à la poignée de résultats que vous poursuivrez aujourd’hui.

Commencez large. Regardez tout ce qui a tourné ou est arrivé depuis votre dernier passage : fils de fond terminés, pull requests en attente, notes de la clôture d’hier, messages qui appellent une réponse, tout ce qu’une tâche automatique a signalé. N’agissez encore sur rien. La tentation est de corriger le premier petit problème que vous voyez, parce que c’est satisfaisant et rapide. Ne le faites pas. Le premier petit problème est rarement le plus important, et dès que vous commencez à corriger, la revue est finie et la journée a été choisie par accident.

Ensuite, resserrez. Pour chaque élément, demandez-vous s’il exige une décision de votre part. Beaucoup n’en exigent pas. Un fil terminé qui a passé ses vérifications n’a peut-être besoin que d’être fusionné, geste de deux secondes que vous pouvez regrouper avec d’autres. Une notification indiquant que quelque chose a bien tourné n’a besoin de rien du tout. Ce qui reste, les éléments qui demandent réellement votre jugement, forme votre liste de décisions. Elle est généralement plus courte que ne le laissait croire la boîte de réception.

Enfin, choisissez. À partir de la liste de décisions et du registre de vos projets, retenez les résultats du jour. Le chapitre suivant en suggère trois, mais le nombre compte moins que l’acte de choisir. Écrivez-les là où vous les verrez toute la journée. Ils sont le contrat que la journée passe avec elle-même.

C’est pendant la revue que la journée se gagne, sans bruit, avant que rien ne se soit passé.

Quelques remarques pratiques. Faites la revue avant d’ouvrir quoi que ce soit qui puisse vous entraîner dans une conversation, car les conversations sont faites pour être poursuivies et la revue est faite pour être terminée. Tenez-la dans un temps limité ; si elle prend quarante minutes chaque matin, c’est que quelque chose en amont produit trop de bruit, et cela mérite d’être corrigé pour soi-même. Et faites-la au même endroit chaque jour, dans le même ordre, pour qu’elle devienne une habitude plutôt qu’une décision. Les décisions coûtent cher au saut du lit. Les habitudes sont gratuites.

Certains opérateurs demandent à un agent de préparer la revue pour eux : un court condensé de ce qui a tourné, de ce qui a réussi, de ce qui a échoué et de ce qui attend. C’est un bon usage d’un agent, à condition que le condensé soit un point de départ et non un substitut. Lisez le condensé, puis jetez un œil aux éléments sous-jacents pour repérer tout ce qui sent mauvais. L’agent sait résumer. Il ne sait pas encore vous dire laquelle des choses résumées vous importera le plus à onze heures.

Essayez demain. Avant d’ouvrir quoi que ce soit, écrivez la date du jour et les mots résultats du jour sur une page blanche. Puis faites la revue, large, resserrée, choix, et remplissez la page. Terminez la revue délibérément, par exemple en fermant l’onglet dans lequel vous l’avez faite. Puis lancez la première session. Remarquez combien la première heure est différente quand elle commence par une décision plutôt que par un défilement.

Lire ce qui a tourné la nuit

L’un des grands plaisirs du travail avec des agents, c’est de se réveiller devant du travail fini. Vous avez briefé un fil avant d’aller dormir, il a tourné pendant votre sommeil, et voilà qu’une pull request, un brouillon, un rapport ou un jeu de données vous attend. On a l’impression d’avoir du personnel. C’est aussi l’un des endroits où l’on commet le plus facilement une erreur discrète et coûteuse, car le travail fait pendant qu’on ne regardait pas est celui qu’on connaît le moins.

La première règle de lecture du travail nocturne est de lire le résultat avant le résumé. Les agents écrivent de bons résumés, et les bons résumés sont persuasifs. Ils vous disent ce qui a été fait, pourquoi, et que tout est passé. Ce ne sont pas des mensonges, mais ils sont rédigés par la partie qui a fait le travail, et ils soulignent naturellement ce qui s’est bien passé. Ouvrez d’abord la production réelle : le diff, le document, les données. Faites-vous votre propre impression. Lisez ensuite le résumé et voyez s’il est d’accord avec vous.

La deuxième règle est de vérifier la preuve, pas seulement son existence. Un fil qui annonce tous les tests passent vous a dit quelque chose, mais vous voulez savoir quels tests, et si l’un d’eux exerce réellement le nouveau travail. Un rapport qui cite des sources doit avoir des sources que vous pouvez ouvrir. Un jeu de données qui revendique cent lignes doit avoir cent lignes. Ces vérifications prennent une minute chacune. C’est la minute qui sépare faire confiance à la machine d’espérer qu’elle avait raison.

Le travail qu’on n’a pas surveillé mérite une première lecture plus lente que l’autre, pas plus rapide.

La troisième règle est de trancher, nettement, entre trois options : le livrer, le renvoyer avec des remarques précises, ou le mettre de côté avec une raison. Ne laissez pas le travail de la nuit dans un état ambigu, ouvert et à moitié lu, car c’est ainsi qu’il devient aussi le quatrième point de la revue de demain. S’il est bon, fusionnez-le ou publiez-le maintenant. S’il demande des changements, écrivez-les sous forme de court brief et relancez le fil. S’il soulève une question à laquelle vous ne pouvez pas encore répondre, notez la question dans le registre à côté du projet et fermez l’onglet.

Un motif mérite d’être remarqué avec le temps. Certains types de travail nocturne reviennent régulièrement bons, d’autres régulièrement confus. Les premiers sont généralement étroits, bien spécifiés et faciles à vérifier. Les seconds sont généralement larges, exploratoires, ou dépendants d’arbitrages que l’agent a dû faire sans vous. Ce n’est pas une raison pour cesser de lancer du travail large la nuit. C’est une raison pour le briefer autrement : demandez des options plutôt qu’une décision, et prévoyez de passer plus de temps à le relire le matin.

Cette semaine, tenez une courte note de chaque résultat nocturne que vous lisez : ce que c’était, si vous l’avez livré, renvoyé ou mis de côté, et combien de temps la lecture a pris. Vendredi, vous saurez quels types de travail peuvent tourner sans danger pendant votre sommeil, et lesquels ont vraiment besoin que vous soyez éveillé. Ce savoir vaut plus que n’importe quel surcroît de capacité des agents, car il vous dit où pointer la capacité que vous avez déjà.

Choisir les trois du jour

Choisissez trois résultats pour la journée. Pas trois tâches, pas trente, et pas un seul. Trois résultats, chacun visiblement terminé à la clôture : livré, envoyé, décidé ou publié. C’est la contrainte la plus utile qu’un opérateur puisse adopter, et elle est utile précisément parce qu’elle paraît trop petite.

Pourquoi trois ? En partie parce que c’est à peu près ce qu’une personne peut relire correctement en une journée quand les agents font l’essentiel du travail. Chaque résultat demandera au moins une relecture attentive, souvent deux ou trois, et chaque relecture exige une attention véritable. En partie parce que trois suffit à absorber une déception : si un résultat cale, la journée en produit encore deux. Et en partie parce que trois est un nombre qu’on peut garder en tête sans l’écrire, même s’il faut l’écrire quand même.

C’est dans le choix que réside le savoir-faire. Une façon utile d’y réfléchir consiste à placer les résultats candidats sur deux axes, l’impact et l’effort. L’impact, c’est ce que changerait le fait de finir : pour un client, pour des utilisateurs, pour la santé de vos projets. L’effort n’est pas celui de l’agent, qui ne coûte presque rien, mais le vôtre : combien de brief, de relecture et de décision il faudra. Les résultats que vous voulez sont forts en impact et modérés en effort pour vous. Ce sont les trois du jour.

Une liste de trente est un vœu. Une liste de trois est un plan.

Méfiez-vous de deux déformations courantes. La première consiste à ne choisir que des résultats faciles, parce que finir fait du bien et que les choses faciles se finissent. Une journée de trois victoires triviales est agréable et ne fait rien bouger d’important. Assurez-vous qu’au moins un des trois soit une chose que vous auriez été un peu réticent à commencer. La seconde consiste à ne choisir que des résultats énormes, parce qu’ils paraissent importants. Un résultat énorme se termine rarement en une journée. Si quelque chose compte mais est gros, le résultat du jour doit en être une tranche qui peut se finir : la première section livrée, le design arrêté, les données nettoyées.

Les trois ne sont pas une prison. Des choses surgiront. Si une urgence arrive, vous pouvez la faire entrer, mais faites-le explicitement : rayez-en un, inscrivez le nouveau, et prenez acte que vous avez fait un échange. Ce qu’il ne faut pas faire, c’est en ajouter un quatrième et un cinquième en silence. C’est ainsi que trois deviennent huit, et que huit deviennent une journée où rien ne se finit tout à fait.

À la clôture, regardez les trois. Marquez chacun comme fait, en partie fait ou pas fait, et écrivez une phrase sur la raison pour ceux qui ont glissé. Au bout de quelques semaines, un motif apparaîtra. Peut-être sous-estimez-vous systématiquement le temps de relecture. Peut-être les après-midi sont-ils le cimetière des résultats. Peut-être choisissez-vous bien le lundi et mal le jeudi. Chaque motif est un levier.

Commencez demain. Pendant la revue du matin, écrivez trois résultats en haut de la page. Faites que chacun soit finissable, précis et digne d’être fait. Puis consacrez la journée à eux, et à eux seuls, sauf échange conscient. C’est une discipline modeste. Son effet sur une semaine ne l’est pas du tout.

Des sessions en blocs de temps

Une session est un bloc de temps doté d’un seul objet. Elle commence par un brief, se termine par une décision, et ne contient rien d’autre. Les opérateurs qui travaillent par sessions abattent plus de travail que ceux qui travaillent au fil de l’eau, pour la même raison qu’une cuisine équipée de minuteurs sert plus de repas qu’une cuisine où tout mijote jusqu’à ce que quelqu’un s’en souvienne.

La structure interne d’une session est simple. Vous écrivez ou chargez le brief, idéalement dans les dix premières minutes. Vous laissez tourner les agents, en regardant assez pour repérer tôt un mauvais virage, mais pas de si près que vous feriez en réalité le travail à travers eux. Vous relisez soigneusement ce qui revient. Et vous décidez : livrer, relancer un tour dans la même session, ou mettre de côté avec une note. La relecture et la décision forment le cœur de la session, et c’est la partie la plus susceptible d’être écrasée si la session n’a pas de fin fixe.

Combien de temps doit durer une session ? Assez pour finir quelque chose, assez peu pour rester vif pendant la relecture. Pour beaucoup, c’est quelque part entre quarante minutes et deux heures. La durée exacte compte moins que le fait de l’avoir décidée à l’avance. Une session à fin fixe change votre comportement dès le départ : vous briefez plus serré, parce que vous savez qu’il restera peu de temps pour rattraper un brief vague.

Donnez un contenant au travail et il y restera presque toujours.

Les sessions rendent aussi le travail parallèle gérable. Avec des agents, il est tentant de lancer de nombreux fils et de dériver de l’un à l’autre. Cela peut marcher, mais cela marche bien mieux quand chaque fil appartient à une session, avec un responsable et une fin. Dans une session, vous pouvez faire tourner trois agents sur trois tranches du même résultat. Ce qu’il faut éviter, c’est cinq fils sur cinq résultats sans rapport, tous à moitié surveillés, aucun correctement relu. Ce n’est pas du travail parallèle. C’est de la négligence parallèle.

Mettez les sessions dans l’agenda, même si l’agenda n’est qu’à vous. Intitulez chacune par son résultat, pas par son activité : livrer le correctif de l’importateur, pas travailler sur l’importateur. Quand la session se termine, arrêtez-vous, même si le travail n’est pas tout à fait fini. Écrivez une courte note sur l’état des lieux, puis planifiez une autre session ou renvoyez le résultat au registre. La discipline de l’arrêt est inconfortable au début. C’est aussi elle qui vous apprend, en quelques semaines, la taille réelle d’un travail à l’échelle d’une session.

Entre les sessions, prenez une vraie pause. Pas une pause passée à consulter d’autres fils, qui n’est qu’une session déguisée, mais une pause pendant laquelle rien n’est relu. Les agents peuvent continuer à tourner. Vous, non. La qualité de votre prochaine relecture dépend bien plus de cette pause que de tout ce que vous auriez pu lire pendant ce temps.

Cette semaine, essayez de faire passer chaque travail par une session : un bloc dans l’agenda, un résultat dans son titre, une décision à sa fin. Comptez combien de sessions vous bouclez chaque jour. Ce nombre, plus que les heures travaillées, mesure bien la capacité réelle d’un opérateur. La plupart des gens le trouvent plus petit qu’ils ne le pensaient, et découvrent que travailler avec lui plutôt que contre lui est un grand soulagement.

Bien démarrer une session

Les cinq premières minutes d’une session décident de l’essentiel de l’heure qui suit. Une session qui démarre proprement, avec le bon contexte chargé et un brief clair, a tendance à se dérouler sans heurts. Une session qui démarre par bon, où en étais-je a tendance à passer sa première moitié à le découvrir, et sa seconde à réparer les suppositions faites pendant qu’elle cherchait.

Le démarrage propre tient en trois gestes. D’abord, lisez la passation. Si ce résultat a déjà été travaillé, une note de la dernière session ou de la clôture d’hier devrait dire où il en est : ce qui a été fait, ce qui reste ouvert, quel devait être le geste suivant. Lisez-la, ainsi que les entrées pertinentes de la mémoire du projet. Cela prend deux minutes et en fait gagner vingt. S’il n’y a pas de passation, cela vous dit quelque chose sur la façon dont la dernière session s’est terminée, ce que vous pourrez corriger plus tard.

Ensuite, écrivez le brief. Même si la session en prolonge une autre, écrivez en quelques phrases à quoi elle sert, à quoi ressemble « fini » et ce que l’agent doit savoir. C’est en partie pour l’agent et en partie pour vous. Écrire le brief vous oblige à décider ce que vous attendez vraiment de l’heure qui vient, et l’acte de décider représente la moitié de la valeur de la session.

Enfin, faites valider le plan avant que le travail ne commence. Pour tout ce qui dépasse une modification triviale, demandez à l’agent d’expliquer comment il compte procéder avant de le faire. Beaucoup d’outils d’agents disposent d’un mode planification précisément pour cela. Lisez le plan. S’il est faux, le corriger maintenant coûte une phrase. Le corriger après quarante minutes de travail coûte les quarante minutes et votre patience.

Un mauvais plan ne coûte pas cher. Un mauvais plan exécuté, si.

Ces gestes semblent tatillons, et pour les petites tâches on peut les comprimer en une seule ligne de brief. Mais l’habitude compte plus que la cérémonie. Les opérateurs qui sautent le démarrage propre accusent souvent l’agent quand une session déraille : il a mal compris, il est parti dans une direction bizarre, il ne connaissait pas la contrainte. Dans la plupart des cas, l’agent travaillait à partir de ce qu’on lui avait donné, c’est-à-dire pas grand-chose.

Un démarrage propre suppose aussi un environnement propre. Fermez les fils qui ne font pas partie de cette session. Débarrassez les onglets de la précédente. Si l’agent travaille dans un dépôt, vérifiez que vous êtes sur la bonne branche et que rien d’inachevé ne traîne depuis avant. Ce sont de petits gestes de rangement, et ils évitent toute une famille d’erreurs déroutantes où l’agent travaille sur une chose pendant qu’un reliquat d’une autre interfère en douce.

Essayez de chronométrer. Pour les cinq prochaines sessions, notez combien de temps prend le démarrage propre, puis évaluez la session après coup sur une échelle simple : fluide, cahoteuse ou perdue. La plupart des opérateurs constatent que les sessions bien démarrées sont bien plus souvent jugées fluides, et que le démarrage a rarement pris plus de cinq minutes. Cinq minutes, c’est un petit prix pour une heure fluide. C’est aussi, fort à propos, à peu près le temps de faire une tasse de thé, et les deux vont très bien ensemble.

Le milieu de la journée

Une fois les agents lancés, l’opérateur fait face à un curieux problème : que faire de lui-même. Le travail avance. Il n’a pas besoin de vos mains. Il a besoin, de temps à autre, de votre jugement, et vous ne savez pas exactement quand. Alors vous planez au-dessus. Vous regardez défiler la sortie, lisez chaque étape intermédiaire, ouvrez les fichiers à mesure qu’ils changent. Cela donne l’impression d’être responsable. C’est surtout une façon de dépenser de l’attention sans rien acheter avec.

L’alternative est un rythme fait de points de passage, de déblocages et de retraits. Passez à intervalles raisonnables, pas en continu. Regardez où en est chaque fil en cours, s’il vous attend, et s’il se dirige vers quelque chose de plausible. Si quelque chose est bloqué sur une question, répondez. Si quelque chose dérive, redirigez-le d’une phrase. Puis éloignez-vous et faites autre chose que regarder : relire un travail fini, écrire le brief de demain, réfléchir à une décision, ou simplement aller marcher.

Le déblocage est la partie précieuse, et il vaut la peine de comprendre pourquoi. Les agents se coincent sur des choses qui exigent une décision qu’ils ne peuvent pas prendre : laquelle de deux approches vous préférez, si une contrainte s’applique vraiment, que faire d’un imprévu. Une heure perdue à attendre cette décision est une heure de temps d’agent gaspillée. Une minute passée à la prendre est la minute au plus fort effet de levier du milieu de journée. Quand vous passez, cherchez donc d’abord ce qui vous attend, et débloquez-le avant tout le reste.

Planer dépense l’attention. Débloquer l’investit.

À quelle fréquence passer ? Cela dépend du travail et de la qualité du brief. Une tâche bien spécifiée, avec des vérifications claires, peut tourner longtemps sans vous. Une tâche exploratoire aux contours flous demande des coups d’œil plus fréquents, car le risque de mauvais virage est plus élevé. Une règle utile consiste à passer à peu près à l’intervalle au bout duquel un mauvais virage deviendrait pénible à défaire. Pour beaucoup de tâches, c’est toutes les quinze ou vingt minutes. Pour certaines, une fois par heure.

Beaucoup d’outils d’agents vous notifient désormais quand un fil attend une réponse ou se termine. Servez-vous de ces notifications, mais réglez-les. Si tout vous notifie, plus rien ne vous notifie. Idéalement, les seules interruptions que vous recevez en milieu de journée sont celles qui demandent une décision, et tout le reste attend votre prochain passage ou votre clôture.

Le milieu de la journée est aussi l’endroit où les choix du matin sont mis à l’épreuve. Si les trois du jour sont bien choisis et les briefs clairs, le milieu est calme : vous passez, débloquez, vous éloignez, et relisez le travail fini à mesure qu’il arrive. Si le milieu paraît frénétique, c’est généralement le symptôme d’un problème en amont. Trop de fils ont été lancés. Un brief était vague. Un résultat était trop gros. Notez le symptôme pour la revue de demain plutôt que d’essayer d’en corriger la cause au milieu de la tempête.

Cette semaine, réglez un minuteur pour vos passages au lieu de regarder en continu. Quand il sonne, regardez, débloquez, et éloignez-vous de nouveau. Voyez quelle part de la journée cela vous rend. Les agents ne remarqueront pas la différence. Vous, si.

Les interruptions et la file

Les idées arrivent à des moments malcommodes. Vous êtes à mi-chemin de la relecture d’une pull request et vous pensez à une fonctionnalité. Vous écrivez un brief et vous vous souvenez d’un e-mail que vous vouliez envoyer. Un message arrive pour demander une petite chose. Un agent, en pleine exécution, suggère d’améliorer tout autre chose. Chacune est une petite interruption, et chacune, si on y donne suite immédiatement, coûte non seulement le temps qu’elle prend mais aussi celui qu’il faut ensuite pour retrouver où l’on en était.

Les agents rendent les interruptions plus dangereuses, parce qu’ils rendent si bon marché le fait d’y donner suite. Dans l’ancien monde, une idée nouvelle en milieu d’après-midi devait attendre, parce que vous étiez occupé. Maintenant, vous pouvez ouvrir un nouveau fil et le lancer en trente secondes, et ces trente secondes semblent gratuites. Elles ne le sont pas. Le nouveau fil demandera brief, surveillance, relecture et décision, et il vient de prélever en douce une part de l’attention du jour déjà promise aux trois du jour.

La réponse est une file d’attente. Quelque part de simple, un fichier texte ou une liste dans votre registre, où les interruptions vont attendre. Quand quelque chose arrive, posez une seule question : faut-il que cela se fasse aujourd’hui, aux dépens des résultats du jour ? Si oui, faites-le maintenant, et échangez-le consciemment contre l’un des trois. Si non, et c’est presque toujours non, inscrivez-le dans la file en une ligne et revenez à ce que vous faisiez. Il sera là à la revue de demain, où il pourra concourir loyalement avec tout le reste.

Une idée notée n’est pas perdue. Une idée exécutée sur-le-champ l’est souvent.

La file fonctionne parce qu’elle supprime l’angoisse de l’oubli. Une bonne part de l’envie de donner suite à une interruption vient de la peur que l’idée s’évanouisse si on ne la saisit pas. Une fois que vous avez confiance dans la file pour la garder et dans la revue pour l’examiner, l’envie s’estompe. Vous pouvez laisser une bonne idée partir dans la file avec le même calme qu’une lettre dans une boîte aux lettres.

Il vaut la peine d’être honnête sur la catégorie « urgent ». Très peu de choses doivent réellement se faire aujourd’hui. Une panne en production, oui. Une promesse faite à un client avec une échéance aujourd’hui, oui. Un message de quelqu’un qui attend votre feu vert pour avancer, peut-être. Presque rien d’autre, aussi urgent que cela paraisse, et le sentiment d’urgence n’est souvent que le sentiment de nouveauté déguisé.

Les agents peuvent aussi aider avec la file. Une bonne habitude consiste à demander aux agents, quand ils remarquent quelque chose hors de la tâche en cours, de le noter plutôt que de le corriger. Si tu trouves d’autres problèmes, liste-les à la fin ; ne les modifie pas est une ligne qui évite énormément de dérive de périmètre. Ces notes vont ensuite dans la file, et la tâche en cours reste la tâche en cours.

Cette semaine, tenez une file et servez-vous-en pour chaque interruption qui n’est pas vraiment urgente. En fin de semaine, regardez ce qui s’est accumulé. Une partie aura de la valeur et sera planifiée. Une part étonnante semblera, le vendredi, n’avoir jamais été si importante. Cette part étonnante, c’est l’attention que vous avez économisée.

La commande de fin

Chaque session devrait se terminer par le même petit rituel. Voyez-le comme une commande de fin : une séquence fixe qui transforme une plage de travail en quelque chose de réglé. Vérifier, livrer, noter, arrêter. Cela prend cinq minutes. C’est la différence entre une session qui s’est finie et une session qui s’est simplement arrêtée parce que vous n’aviez plus de temps.

Vérifiez d’abord. Avant toute chose, assurez-vous que ce que vous croyez fait l’est réellement. Relancez les vérifications si la dernière exécution date d’avant les ultimes modifications. Ouvrez la page, lisez le document, regardez les données. Les agents sont doués pour annoncer qu’ils ont fini ; ils ne sont pas infaillibles en la matière, et la fin d’une session, quand vous avez hâte de passer à autre chose, est précisément le moment où vous êtes le plus enclin à les croire sur parole.

Puis livrez. Si le travail est prêt, mettez-le à sa place : fusionnez la pull request, publiez le billet, envoyez l’e-mail, mettez à jour la fiche. Ne laissez pas un travail fini dormir dans une branche ou un dossier de brouillons pendant la nuit. Il ne s’y améliorera pas, et il deviendra un point de la revue de demain qui vous obligera à reconstruire de zéro votre confiance en lui. S’il n’est pas prêt, décidez explicitement qu’il ne l’est pas, et pourquoi.

Puis notez. Écrivez une courte passation : ce qui a été fait, ce qui reste ouvert, quel est le geste suivant. Placez-la là où la prochaine session regardera, que ce soit le fichier de mémoire du projet, le registre, ou une note en tête du fil. Écrivez-la pour quelqu’un qui a tout oublié, car demain, ce quelqu’un, ce sera vous. Beaucoup d’opérateurs demandent à un agent de rédiger cette note puis la corrigent, ce qui est une bonne division du travail tant que la correction a réellement lieu.

Une session qui se termine sans note se termine deux fois : maintenant, et demain quand vous chercherez ce qui s’est passé.

Puis arrêtez. Fermez le fil, ou laissez-le tourner exprès avec une tâche claire s’il s’agit d’un long travail de fond. Fermez les onglets. Levez-vous. L’arrêt fait partie de la commande, ce n’est pas un après-coup, car une session qui ne s’arrête pas déborde sur la suivante et la brouille.

Certains opérateurs en font une vraie commande : une courte instruction enregistrée qu’ils collent ou invoquent en fin de session, et qui demande à l’agent de lancer les dernières vérifications, de résumer l’état des choses, de lister les questions ouvertes et de rédiger la note de passation. C’est une bonne idée, et cela rend le rituel assez facile pour être fait à chaque fois. La commande ne vaut toutefois que par votre volonté de lire ce qu’elle produit. Il ne s’agit pas d’automatiser la fin. Il s’agit de s’assurer que la fin a lieu.

Cette semaine, terminez chaque session par les quatre étapes, dans l’ordre, même fatigué, même quand la session s’est mal passée. Surtout quand elle s’est mal passée. Une mauvaise session assortie d’une bonne note se rattrape demain en cinq minutes. Une mauvaise session sans note a tendance à rester mauvaise pendant des jours. La commande de fin est ce qui transforme une heure d’effort en une heure de progrès, et elle coûte moins que l’effort qu’elle protège.

Clôturer la journée

La clôture, ce sont les vingt dernières minutes de la journée d’exploitation, et c’est la partie que la plupart des opérateurs sautent. Elle paraît facultative. Le travail est fait, ou pas, et rien ne changera si on la remet au lendemain matin. Mais la clôture ne concerne pas aujourd’hui. Elle concerne la revue de demain matin, et la soirée qui s’intercale entre les deux.

Commencez par noter ce qui a été livré. Regardez les trois du jour et cochez chacun. Notez tout ce qui s’est fini par ailleurs. Cela prend une minute et produit un effet sans rapport avec sa taille : une vague impression d’avoir été occupé devient une trace concrète de ce qui a changé. Les bons jours, la trace est satisfaisante. Les mauvais jours, elle est instructive. Dans les deux cas, elle vaut mieux que l’impression que vous auriez autrement emportée au lit.

Notez ensuite ce qui reste ouvert. Chaque fil en plein vol, chaque relecture à moitié faite, chaque question dont vous attendez la réponse de quelqu’un. Pour chacun, une ligne : où il en est et quel est le geste suivant. Si vous écrivez des notes de passation à la fin de chaque session, cette étape consiste surtout à les rassembler. Sinon, c’est ici que vous découvrez pourquoi vous devriez.

Écrivez ensuite demain. Pas un plan complet, qui est le travail de la revue du matin, mais une impulsion : la première chose que vous comptez regarder, et peut-être un candidat pour l’un des trois de demain. Commencer la matinée avec une suggestion de votre moi passé rend la revue bien plus rapide. Cela vous permet aussi de vous défaire de toute inquiétude persistante. Si quelque chose vous tracasse, écrivez-le dans cette section, pour qu’il ait un endroit où vivre qui ne soit pas votre tête.

Écrivez demain pour que ce soir puisse être ce soir.

Puis arrêtez-vous. Décidez quels agents, s’il y en a, continueront à travailler pendant la nuit, et assurez-vous que chacun a une tâche claire et bornée ainsi qu’une vérification qu’il peut lancer. Mettez en pause tout ce qui n’a pas besoin de tourner. Fermez l’ordinateur. L’arrêt n’est pas une récompense pour avoir fini ; c’est une pièce structurelle de la machine. Un opérateur qui ne s’arrête jamais n’en fait pas davantage. Il en fait autant, en moins bien, avec moins de jugement, et il n’en découvre le coût que lorsqu’une relecture fatiguée laisse passer ce qui aurait dû être attrapé.

Il existe une tentation, surtout quand des agents tournent, de passer voir une dernière fois après la clôture. Le fil a peut-être fini. Il y a peut-être quelque chose d’intéressant. Résistez. Quoi qu’il se soit passé, ce sera encore là au matin, et la revue du matin est conçue pour s’en occuper calmement. Regarder tard le soir remplace une revue matinale sereine par une revue nocturne anxieuse, ce qui est un mauvais échange à tous points de vue.

Ce soir, faites une vraie clôture. Vingt minutes : livré, encore ouvert, demain, arrêt. Puis observez comment se passe la revue de demain matin. La plupart des gens la trouvent plus rapide, plus calme et plus décidée. La clôture ne fait pas que terminer la journée. Elle commence la suivante, discrètement, pendant que vous regardez ailleurs.

Un brief est un contrat

Le brief est le document qui transforme votre intention en travail d’agent. Il peut tenir en une phrase ou en une page, être tapé dans une fenêtre de discussion ou enregistré dans un fichier, mais dans tous les cas il remplit la même fonction : il dit ce que vous voulez, ce que l’agent doit savoir, ce qu’il ne doit pas faire et comment vous jugerez le résultat. Quand le brief est bon, le travail a tendance à l’être aussi. Quand le brief est médiocre, le travail est souvent médiocre de façon impressionnante et pleine d’assurance.

Il est utile de considérer un brief comme un contrat plutôt que comme une demande. Une demande est une chose dont on espère qu’elle sera satisfaite. Un contrat est une chose à laquelle les deux parties peuvent se référer après coup. La différence apparaît au moment de la relecture. Si votre brief disait améliorer la page d’accueil, vous n’avez aucun moyen de savoir si le résultat le respecte, puisqu’on peut défendre presque n’importe quel changement comme une amélioration. Si votre brief disait le titre de la page d’accueil tient sur une ligne sur un téléphone, et le bouton d’inscription est visible sans faire défiler, vous pouvez vérifier en dix secondes.

Un contrat utile comporte quatre parties, empilées de haut en bas. Le but : une phrase, formulée comme un résultat. Le contexte : tout ce que l’agent doit savoir et ne peut pas facilement découvrir, comme le public visé, les fichiers qui comptent ou ce qui a déjà été tenté. Les contraintes : ce qui ne doit pas changer, les outils ou approches interdits, jusqu’où le travail peut s’étendre. Et la définition de « fini » : les vérifications qui vous diront, à l’un comme à l’autre, que le travail est terminé. Cette dernière couche est la fondation, et c’est pourquoi elle se trouve en bas. Tout ce qui est au-dessus en dépend.

Si vous ne pouvez pas le vérifier, vous ne l’avez pas demandé. Vous l’avez espéré.

Tous les briefs n’ont pas besoin des quatre parties en toutes lettres. Une petite tâche dans un projet familier peut se contenter d’un but et d’une vérification, parce que le contexte et les contraintes figurent déjà dans la mémoire du projet. Mais il vaut la peine de passer mentalement les quatre parties en revue à chaque fois, car celle qu’on saute est généralement celle qui pose problème. Un contexte manquant produit un travail plausible visant la mauvaise cible. Des contraintes manquantes produisent un travail qui s’étend là où vous ne vouliez pas qu’on touche. Une définition de « fini » manquante produit des disputes avec vous-même au moment de la relecture.

Écrire ses briefs ainsi change aussi la façon dont on pense le travail avant qu’il commence. Souvent, au moment d’écrire la définition de « fini », on découvre qu’on ne sait pas ce que « fini » veut dire. Ce n’est pas un échec du brief. C’est le brief qui fait son travail tôt, avant qu’un agent n’ait passé une heure à construire en direction d’une cible que vous n’aviez pas choisie.

Cette semaine, prenez les trois prochaines tâches que vous auriez d’ordinaire expédiées en une phrase et rédigez-les plutôt comme des contrats en quatre parties. Gardez chaque partie courte, une ligne ou deux. Puis comparez les résultats à ce que vous obtenez d’habitude. Les agents ne sont pas devenus plus intelligents. Vous leur avez simplement dit, pour la première fois, à quoi ressemblerait l’intelligence.

Commencer par la fin

Si vous ne deviez changer qu’une seule habitude dans votre façon de briefer les agents, changez celle-ci : écrivez la définition de « fini » avant d’écrire la tâche. Pas après, comme une pensée de dernière minute, et pas implicitement, en supposant que l’agent saura. D’abord. C’est le moyen le plus fiable d’améliorer la qualité de ce qui revient.

La raison en est que « fini » est l’endroit où loge votre jugement. La description de la tâche dit sur quoi travailler ; la définition de « fini » dit ce que vous accepterez. Un agent peut travailler avec compétence sur à peu près n’importe quoi, mais il ne peut pas lire vos exigences dans l’air ambiant. Quand il ne sait pas ce que vous accepterez, il fait une supposition raisonnable, et les suppositions raisonnables se trompent juste assez souvent pour coûter cher.

Écrire « fini » en premier vous protège aussi d’un piège précis. Si vous écrivez d’abord la tâche, la définition de « fini » a tendance à être modelée par la tâche : ajouter un filtre au tableau devient le tableau a un filtre. C’est circulaire. Si vous écrivez « fini » d’abord, vous partez du résultat qui vous importe réellement : un utilisateur trouve les commandes du mois dernier en moins de dix secondes. La tâche en découle alors, et pourrait se révéler être un filtre, ou un champ de recherche, ou un ordre de tri par défaut. Commencer par la fin laisse de la place pour une meilleure tâche que celle à laquelle vous aviez d’abord pensé.

La tâche, c’est le comment. La fin, c’est le pourquoi. Écrivez le pourquoi d’abord.

Les bonnes définitions de « fini » ont des traits communs. Elles sont observables : quelqu’un pourrait les vérifier sans lire dans vos pensées. Elles sont précises : elles nomment un chiffre, un comportement ou un état plutôt qu’une qualité. Et elles comprennent au moins une vérification qui échouerait si le travail manquait. Tous les tests passent est faible, car tous les tests passaient peut-être déjà avant que vous ne commenciez. Un nouveau test couvre le cas du fichier vide, échoue sur le code actuel et passe après la modification est solide, car il prouve que la modification a fait quelque chose.

Pour le travail qui n’est pas du code, le principe est identique. Un rapport est fini quand il répond aux trois questions pour lesquelles il a été commandé, cite une source pour chaque affirmation et tient sur deux pages. Un design est fini quand il fonctionne à la largeur d’un téléphone, ne contient aucun texte plus petit qu’une taille donnée et n’utilise que les couleurs convenues. Un e-mail est fini quand il se lit en moins d’une minute et ne demande qu’une seule chose. Aucune de ces définitions n’est difficile à écrire. Toutes sont régulièrement omises.

Une fois la définition de « fini » en main, donnez-la à l’agent et demandez-lui de s’y confronter avant de vous rendre compte. Beaucoup d’agents le font désormais naturellement si on le leur demande : lancer les vérifications, citer les résultats, signaler tout ce qui n’atteint pas la barre. Votre relecture passe alors d’une inspection sans bornes à une confirmation, ce qui est plus rapide et bien moins fatigant.

Cette semaine, écrivez Fini quand : en première ligne de chaque brief, et remplissez-la avant toute autre chose. Si vous n’y arrivez pas, arrêtez-vous et réfléchissez, car le travail n’est pas encore prêt à être délégué. Il est prêt à être décidé.

Du contexte, pas une biographie

Les agents ont besoin de contexte. Ils ont besoin de savoir sur votre projet, votre public et votre situation des choses qu’ils ne peuvent pas découvrir en regardant. La difficulté, c’est que vous en savez énormément, et que l’essentiel n’a aucun rapport avec une tâche donnée. L’art du brief consiste à donner le contexte dont la tâche a besoin, et rien de plus : du contexte, pas une biographie.

Imaginez deux cercles qui se chevauchent. L’un contient tout ce que vous savez : l’histoire du projet, vos préférences, les manies du client, les trois approches rejetées le printemps dernier, votre opinion sur les points-virgules. L’autre contient tout ce dont la tâche a besoin pour être bien faite. Le brief devrait contenir l’intersection et presque rien d’autre. Trop peu, et l’agent travaille à l’aveugle. Trop, et l’agent accorde du poids à des choses sans importance, ou perd le détail crucial dans le bruit.

En dire trop est le problème le plus fréquent chez les opérateurs consciencieux. Ils craignent que l’agent ne rate quelque chose, alors ils mettent tout. Le brief enfle jusqu’à une page d’historique, de réserves et d’apartés. L’agent, qui prend au sérieux tout ce qu’on place devant lui, s’efforce désormais d’honorer le tout. Une mention en passant du fait que le client n’a jadis pas aimé le bleu devient une contrainte de design. Une vieille approche abandonnée, décrite pour mémoire, ressuscite en partie. Le travail revient façonné par la biographie plutôt que par la tâche.

Chaque phrase d’un brief est une instruction, que vous l’ayez voulu ou non.

Un bon test pour chaque élément de contexte consiste à se demander : si l’on retirait cette phrase, le résultat serait-il vraisemblablement moins bon ? Si oui, gardez-la. Si vous n’êtes pas sûr, gardez-la mais précisez son statut : pour information seulement, ne pas agir là-dessus. Si non, coupez. Vous pourrez toujours ajouter du contexte ensuite si l’agent le demande ou si le résultat montre qu’il en fallait.

L’autre moitié du savoir-faire consiste à repérer ce que l’agent ne peut pas trouver seul. Un agent qui travaille dans un dépôt peut lire le code ; inutile de le lui décrire. Il ne peut pas lire vos conversations avec le client, la décision que vous avez prise sous la douche, ni le fait que le serveur de préproduction est en panne cette semaine. Ce sont exactement les choses à inclure. Indiquez-lui ce qu’il peut trouver, dites-lui ce qu’il ne peut pas trouver.

Il vaut aussi la peine de séparer le contexte stable du contexte de la tâche. Le contexte stable, ce qui reste vrai d’une tâche à l’autre, a sa place dans la mémoire du projet, où chaque session le verra. Le contexte de la tâche, ce qui ne compte qu’ici, a sa place dans le brief. Mélanger les deux revient à se répéter dans chaque brief, ou pire, à oublier de le faire et à obtenir des résultats incohérents. Une partie ultérieure de ce livre traite la mémoire en détail.

Cette semaine, reprenez un brief déjà écrit et passez-le phrase par phrase au test du retrait. Coupez tout ce qui échoue. Puis envoyez le brief raccourci et comparez. La plupart des opérateurs sont surpris de voir qu’un contexte plus mince produit un travail plus net. Les agents, comme les gens, font mieux quand on leur dit ce qui compte plutôt que tout ce qui s’est jamais passé.

Les contraintes sont une gentillesse

Il peut sembler peu généreux de remplir un brief de restrictions. Ne modifie pas l’interface publique. N’ajoute pas de dépendances. Ne touche pas au code de facturation. Reste sous les trois cents mots. N’utilise que les couleurs existantes. On dirait une liste d’interdits, et beaucoup de gens l’adoucissent d’instinct ou la suppriment, en espérant que l’agent fera preuve de bon sens. Mais les contraintes ne sont pas un manque de confiance. Ce sont une gentillesse, envers l’agent et envers votre futur vous.

Un agent sans contraintes doit deviner où se trouvent les bords de la tâche. Doit-il remanier, au passage, la fonction brouillonne d’à côté ? Doit-il mettre à jour la dépendance qui déclenche un avertissement ? Doit-il réécrire l’introduction, puisqu’elle est faible elle aussi ? Chacune de ces initiatives est raisonnable, et chacune élargit la modification, la relecture et le risque. Les agents ont tendance à vouloir aider, et l’aide sans bords s’étale.

Avec des contraintes, l’agent peut se concentrer. Il sait ce qu’il peut toucher et ce qu’il ne peut pas, alors il dépense son effort à l’intérieur de la limite. Le travail revient plus petit, plus cohérent et bien plus facile à relire. Vous n’avez pas à passer vingt minutes à démêler, dans une grosse modification, ce qui relevait de la tâche et ce qui relevait de l’enthousiasme.

Une clôture n’est pas une cage. C’est la description du jardin.

Les contraintes les plus utiles se rangent en quelques familles. Les contraintes de périmètre disent ce qui peut changer : ces fichiers, cette section, cette fonctionnalité seulement. Les contraintes d’interface disent ce qui ne doit pas changer : l’API, la structure des URL, le ton, le format des données. Les contraintes d’outillage disent comment le travail peut être fait : pas de nouvelles bibliothèques, pas d’appels réseau, pas de changement de configuration. Et les contraintes de taille disent quelle ampleur peut avoir le résultat : un nombre de mots, de lignes, d’options. Choisissez celles qui comptent pour la tâche. En général, deux ou trois suffisent.

Une habitude complémentaire rend les contraintes encore plus efficaces : demandez à l’agent de vous prévenir quand une contrainte le gêne. Parfois, la bonne correction exige vraiment de modifier l’interface ou d’ajouter une bibliothèque. Vous voulez le savoir, mais vous voulez le décider, plutôt que de le découvrir dans le diff. Une ligne comme si tu penses qu’une contrainte doit être enfreinte, arrête-toi et explique pourquoi avant de le faire transforme les contraintes de murs en points de contrôle.

Les contraintes sont aussi une archive. Quand vous relirez un brief dans un mois, les contraintes vous diront ce que vous protégiez et pourquoi. C’est souvent plus utile que la description de la tâche, car cela saisit les parties du projet que vous jugiez fragiles ou importantes à ce moment-là.

Cette semaine, ajoutez une ligne Ne pas à chaque brief, avec deux ou trois contraintes précises. Remarquez comme la taille des modifications rétrécit, et combien les relectures deviennent plus rapides. Vous n’avez pas limité l’agent. Vous l’avez orienté, ce qui est une chose différente et bien plus utile.

Nommer les fichiers, nommer les tests

Le moyen le plus rapide d’améliorer un brief est de remplacer les descriptions par des pointeurs. Au lieu de la partie du code qui gère les envois de fichiers, écrivez le chemin du fichier. Au lieu de la commande de test habituelle, écrivez la commande. Au lieu de un style comme nos autres pages, nommez une page. Un pointeur est plus court qu’une description, plus précis, et impossible à mal lire.

Les agents sont très doués pour suivre des pointeurs. Donnez-leur un chemin, et ils ouvriront le fichier, le liront et s’orienteront. Donnez-leur une description, et ils chercheront, trouveront plusieurs candidats, choisiront le plus plausible et continueront. En général, ils choisissent bien. Quand ils choisissent mal, ils le font avec assurance, et vous découvrez l’erreur à la relecture, une fois le travail bâti sur la mauvaise fondation. Copier un chemin vous coûte cinq secondes. Cela épargne la recherche de l’agent et votre doute.

Il en va de même des exemples. Si vous voulez qu’un nouveau composant ressemble à un composant existant, désignez l’existant. Si vous voulez un rapport structuré comme celui du mois dernier, désignez celui du mois dernier. Si vous voulez le ton d’un e-mail particulier, collez-le ou donnez le lien. Les exemples portent une quantité énorme d’instructions implicites qu’il faudrait des paragraphes pour décrire, et qui resteraient décrites imparfaitement.

Et il en va de même, par-dessus tout, des vérifications. Nommez la commande, la page, la requête ou le test exact qui confirmera le travail. Non pas assure-toi que ça marche, mais lance npm test ; le nouveau test dans upload.test.ts doit passer. Non pas vérifie que c’est joli, mais charge /pricing à la largeur d’un téléphone et confirme que rien ne déborde. Une vérification nommée est une chose que l’agent peut réellement exécuter, et que vous pouvez réellement confirmer. Une vérification sans nom est une aspiration.

Un pointeur est une phrase que l’agent ne peut pas mal comprendre.

Cette habitude rapporte deux fois. Une fois dans la qualité de la première tentative, parce que l’agent démarre au bon endroit avec le bon modèle. Et une seconde fois à la relecture, parce que vous savez exactement où regarder. Si le brief nommait trois fichiers et une vérification, votre relecture commence par ces trois fichiers et cette vérification. Vous ne fouillez pas une grosse modification en essayant de reconstituer ce qu’elle était censée faire.

Elle révèle aussi les lacunes de votre propre compréhension. Si, au moment de nommer les fichiers, vous vous apercevez que vous ignorez lesquels sont concernés, c’est précieux à savoir avant que l’agent ne commence. Vous pouvez demander à l’agent de le découvrir d’abord, dans une petite tâche séparée : liste les fichiers impliqués dans les envois et décris chacun en une ligne. Puis briefez le vrai travail, pointeurs en main. Deux petites tâches avec de bons pointeurs battent souvent une grosse tâche avec des pointeurs vagues.

Cette semaine, relisez chaque brief avant de l’envoyer et soulignez chaque description qui pourrait être remplacée par un pointeur. Remplacez-les toutes : un chemin, un exemple, une commande. Cela paraît pédant pendant environ deux jours. Ensuite, cela paraît la façon évidente d’écrire, et les briefs vagues que vous envoyiez autrefois commencent à ressembler à des devinettes que vous posiez sans raison valable.

Le brief en un paragraphe

La plupart des briefs tiennent en un paragraphe. Pas tous, et les exceptions existent, mais la plupart. Une phrase de but, une ou deux phrases de contexte, une phrase de contraintes et une phrase de définition de « fini ». Cinq ou six phrases, une centaine de mots, et l’agent a tout ce qu’il lui faut. Si vos briefs dépassent régulièrement la page, il vaut la peine de se demander pourquoi.

La raison habituelle, c’est que la réflexion n’était pas terminée quand l’écriture a commencé. Un long brief est souvent la trace d’un opérateur en train de chercher ce qu’il veut : options envisagées, inquiétudes exprimées, demi-décisions laissées en suspens. Toute cette réflexion était nécessaire. Rien de tout cela n’a besoin de figurer dans le brief. Le brief est la conclusion, pas le brouillon de calcul.

Traitez donc le brief en un paragraphe comme une discipline. Écrivez d’abord librement si vous en avez besoin, dans un carnet ou un fichier de brouillon. Puis distillez : prenez tout ce que vous savez, ne gardez que ce dont la tâche a besoin, et comprimez-le en un paragraphe. Si vous n’y arrivez pas, deux explications sont probables. Soit la tâche en recouvre en réalité plusieurs et devrait être découpée, soit vous n’avez pas encore tranché une question que l’agent aura besoin de voir tranchée. Les deux méritent d’être découvertes avant que le travail ne commence.

Un long brief est souvent un brief court qui n’a pas fini d’être écrit.

Voici la forme, en prose plutôt qu’en gabarit. But : les utilisateurs peuvent exporter leurs éléments enregistrés sous forme de tableur depuis la page du compte. Contexte : la page du compte se trouve dans app/account, les éléments enregistrés viennent de la requête existante items, et nous utilisons déjà une bibliothèque d’export tableur dans reports/. Ne pas : ajouter de nouvelles dépendances ni modifier la requête des éléments. Fini quand : un nouveau bouton d’export apparaît, le fichier exporté s’ouvre dans un tableur avec une ligne par élément, et un test couvre le cas vide. C’est le brief entier. Un agent peut en tirer un excellent travail, et vous pouvez relire ce travail en dix minutes.

Il existe d’honnêtes exceptions. Le brief d’un travail volumineux en plusieurs étapes peut demander davantage de structure : une courte liste de phases, chacune avec sa propre définition de « fini ». Le brief d’un travail créatif peut exiger des exemples qui prennent de la place. Le brief d’un travail délicat dans un domaine peu familier peut demander plus de contexte qu’à l’ordinaire. Mais même alors, la version en un paragraphe est une première étape utile. Écrivez-la, puis n’ajoutez que ce que le paragraphe ne peut vraiment pas porter.

Les briefs courts ont une autre vertu qu’on remarque mal : ils sont réutilisables. Un paragraphe peut être enregistré, adapté et renvoyé le mois suivant avec quelques mots changés. Une page de réflexion emmêlée, non. Avec le temps, l’opérateur qui écrit des briefs en un paragraphe s’en constitue une bibliothèque, et une bibliothèque de bons briefs est l’un des actifs les plus précieux que puisse avoir une activité d’une seule personne.

Cette semaine, fixez-vous la limite d’un paragraphe pour chaque brief. Quand vous la dépassez, arrêtez-vous et demandez-vous laquelle des deux explications s’applique : trop de tâches, ou pas assez de décisions. Corrigez cela au lieu d’écrire davantage. Le paragraphe vous en remerciera, et l’agent aussi.

Signaler l’écart

Aucun brief ne survit tout à fait intact au contact du travail. L’agent ouvre le fichier et découvre que la fonction que vous avez nommée n’existe plus. La bibliothèque que vous lui avez demandé d’utiliser ne gère pas le format dont vous avez besoin. La contrainte que vous avez posée, fort raisonnablement, rend la tâche impossible telle qu’elle est spécifiée. À ce moment, l’agent a le choix : faire discrètement autre chose, ou vous le dire. Vous voulez qu’il vous le dise, à chaque fois, et il faut le lui demander explicitement.

Livrés à eux-mêmes, les agents ont tendance à s’adapter. C’est en général une force ; vous ne voulez pas d’un agent qui s’arrête à chaque petite surprise. Mais l’adaptation devient un problème quand elle franchit une ligne qui vous importait. Si l’agent décide de son propre chef d’ajouter une dépendance, de modifier une interface, de sauter une vérification qui échouait ou de réinterpréter le but, vous ne le découvrirez qu’à la relecture, si vous le découvrez. Le travail aura l’air complet. Ce sera simplement un autre travail que celui que vous aviez demandé.

Le remède est une consigne permanente unique, qui a sa place dans chaque brief ou, mieux, dans la mémoire du projet : si tu dois t’écarter du brief, signale-le clairement en tête de ton compte rendu, explique pourquoi, et si l’écart est important, arrête-toi et demande avant de continuer. C’est une petite ligne qui change la forme de la collaboration. L’agent continue de s’adapter aux petites surprises, mais les écarts importants arrivent sous forme de questions plutôt que de faits accomplis.

Un écart silencieux est une décision que quelqu’un d’autre a prise à votre place.

Qu’est-ce qui compte comme important ? Cela dépend du projet, mais certains écarts devraient toujours être signalés : modifier quoi que ce soit figurant dans les contraintes, ajouter ou retirer des dépendances, altérer une interface publique, sauter ou affaiblir un test, changer l’interprétation du but, ou toucher des fichiers hors du périmètre annoncé. Vous pouvez les lister une fois pour toutes dans votre fichier de mémoire et vous y référer à jamais.

Quand un écart est signalé, traitez-le comme un point de décision, pas comme un désagrément. Parfois l’agent a raison et le brief avait tort : la fonction a été renommée, la bibliothèque n’en est pas capable, la contrainte reposait sur une hypothèse dépassée. Approuvez l’écart et, si c’est important, mettez à jour le brief ou la mémoire pour que la même surprise ne se reproduise pas. Parfois l’agent a tort : il a mal compris la contrainte ou pris un raccourci. Redirigez-le. Dans les deux cas, c’est vous qui avez tranché, et le travail qui revient est celui que vous avez choisi.

Avec le temps, les écarts signalés deviennent l’une de vos meilleures sources d’information sur un projet. Ils vous montrent où le brief et la réalité ont divergé, ce qui signifie généralement que votre modèle mental du projet est quelque part périmé. Un opérateur qui lit attentivement les écarts en apprend davantage sur son propre système que celui qui se contente de relire des diffs.

Cette semaine, ajoutez la consigne d’écart à chaque brief, ou placez-la une fois pour toutes dans la mémoire du projet. Puis regardez ce qui revient. Vous verrez le jugement de l’agent d’une façon nouvelle : non plus caché dans le travail, mais étalé devant vous, là où vous pouvez l’approuver, le contredire ou en tirer des leçons.

Les exemples battent les adjectifs

Les adjectifs sont les mots les plus faibles d’un brief. Fais-le épuré. Fais-le professionnel. Fais-le chaleureux sans être trop familier. Fais-le moderne. Chacun de ces mots signifie quelque chose pour vous et quelque chose de légèrement différent pour l’agent, et c’est dans l’écart entre les deux sens que naît le travail décevant. Le remède consiste à remplacer les adjectifs par des exemples chaque fois que c’est possible.

Un exemple porte bien plus d’information qu’un adjectif. Chaleureux sans être trop familier pourrait décrire mille tons. Coller deux e-mails que vous avez écrits et qui trouvent la note juste en décrit exactement un. Mise en page épurée est une vague aspiration. Désigner une page dont vous admirez la mise en page est une spécification. L’agent peut voir l’exemple, en remarquer les traits et les reproduire, y compris des traits que vous n’auriez jamais pensé à décrire parce que vous n’en aviez pas conscience.

Imaginez que les façons de demander quelque chose se répartissent sur deux axes. L’un est la précision : à quel point la demande est spécifique. L’autre oppose montrer et dire : décrivez-vous ce que vous voulez, ou en désignez-vous un exemplaire ? Le dire vague est le royaume des adjectifs, et il produit les résultats les plus variables. Le montrer précis, un vrai exemple accompagné d’une note sur ce qu’il faut en garder, produit les plus fiables. C’est dans ce coin-là que vous voulez placer vos briefs.

On ne peut pas décrire un goût. On peut en partager un échantillon.

Il y a plusieurs façons de bien utiliser les exemples. Désignez l’exemple et dites ce qu’il faut en tirer : reprends la structure et le ton de ce rapport, mais pas sa longueur. Donnez plusieurs exemples quand vous voulez que l’agent en déduise un motif plutôt que de copier un cas unique. Donnez un contre-exemple quand il existe un écueil courant à éviter : pas comme celui-ci, trop formel. Et quand vous n’avez pas d’exemple, demandez d’abord à l’agent deux ou trois options courtes, puis choisissez-en une et servez-vous-en comme exemple pour le vrai travail.

Les exemples fonctionnent au-delà de l’écriture et du design. Pour des données, montrez un échantillon du format de sortie voulu. Pour du code, désignez une fonction existante écrite dans le style que vous préférez. Pour une recherche, montrez un résumé que vous avez trouvé utile et demandez-en d’autres du même genre. Dans chaque cas, l’exemple fait le travail qu’un paragraphe d’adjectifs tenterait de faire, en vain.

Il vaut la peine de constituer une petite collection d’exemples auxquels vous revenez souvent : quelques textes dans votre voix, quelques designs dans votre style, quelques rapports dans la forme que vous préférez. Gardez-les à portée de main. Quand vous écrivez un brief, attrapez-les d’abord. Avec le temps, ils deviennent une sorte de goût portatif, une façon de transmettre vos exigences à un agent en quelques secondes plutôt que de les décrire de nouveau à chaque fois.

Cette semaine, traquez chaque adjectif dans vos trois prochains briefs et demandez-vous si un exemple pourrait le remplacer. Quand c’est possible, faites l’échange. Le travail qui reviendra vous ressemblera davantage, parce que, d’une façon modeste mais réelle, il sera construit à partir de morceaux de vous.

Des briefs qui survivent à la session

Certains briefs servent une fois. Beaucoup d’autres, non. Si vous vous surprenez à écrire à peu près le même brief pour la troisième fois, qu’il s’agisse de préparer un résumé hebdomadaire, de relire une pull request, de rédiger un point d’étape pour un client ou de nettoyer un jeu de données, alors ce brief n’en est plus un. C’est une recette, et les recettes méritent d’être correctement écrites et conservées.

La plupart des outils d’agents proposent désormais une façon d’enregistrer et de réutiliser des instructions : prompts enregistrés, commandes personnalisées, skills, modèles ou fichiers de projet qu’un agent peut charger à la demande. Les noms et les mécanismes varient et continueront de changer. Le principe, non. Une tâche récurrente doit avoir un brief récurrent, rangé là où vous et les agents pouvez le trouver, et affiné à chaque usage.

L’astuce est de ne pas écrire la recette trop tôt. Une recette écrite après une seule exécution est une supposition sur ce qui comptera. Une recette écrite après trois ou quatre exécutions à la main saisit ce que vous avez réellement appris : le contexte qu’il fallait sans cesse redonner, la contrainte qu’il fallait sans cesse ajouter, la vérification qui a attrapé le problème deux fois. Le cycle suit donc un ordre précis. Faites la tâche à la main quelques fois avec des briefs ordinaires. Puis distillez ce qui a marché en une recette. Puis réutilisez-la, en notant où elle pèche, et réinjectez ces notes dans la version suivante.

Faites-le trois fois avant de l’écrire. Ensuite, ne l’écrivez plus jamais.

Une bonne recette ressemble à un bon brief dont les parties variables sont signalées. Le but est fixe, ou presque. Le contexte est en grande partie stable, avec un emplacement pour les détails de l’exécution en cours. Les contraintes sont fixes. La définition de « fini » est fixe. Quand vous l’utilisez, vous remplissez les emplacements, et tout le reste vient gratuitement. Beaucoup d’opérateurs conservent leurs recettes sous forme de simples fichiers texte, avec un court en-tête indiquant quand s’en servir, format qui survivra à n’importe quel outil.

Les recettes portent aussi vos exigences vers l’avant. Dès qu’une recette inclut la vérification qui attrape une erreur courante, chaque exécution future l’inclut, que vous pensiez à la demander ou non. C’est l’une des façons les plus discrètes dont une activité s’améliore avec le temps. Chaque erreur attrapée devient une ligne de recette, et chaque recette rend l’exécution suivante un peu plus sûre que la précédente.

Méfiez-vous du pourrissement des recettes. Une recette écrite il y a six mois peut renvoyer à des fichiers qui ont bougé, à des outils qui ont changé ou à des exigences que vous n’avez plus. Quand une recette produit un mauvais résultat, vérifiez la recette avant d’accuser l’agent. Souvent, la correction tient en une ligne ou deux, et elle améliore toutes les exécutions futures. Une courte revue de toutes vos recettes une fois par trimestre, pour supprimer les inutilisées et rafraîchir les périmées, garde la collection honnête.

Cette semaine, parcourez vos briefs récents et trouvez-en un que vous avez écrit au moins trois fois. Transformez-le en recette : but, contexte avec emplacements, contraintes, définition de « fini ». Rangez-la là où vous la retrouverez. La prochaine fois que la tâche se présente, utilisez la recette au lieu de repartir de zéro, et voyez quelle part de votre attention elle vous rend.

La bibliothèque de recettes

Au fil des mois, un opérateur en activité accumule un ensemble de recettes : des briefs réutilisables pour les tâches qui reviennent sans cesse. Au début, elles vivent là où elles ont été écrites, éparpillées entre dossiers et fils. À un moment donné, il devient rentable de les rassembler en un seul endroit, une bibliothèque, et de traiter cette bibliothèque comme l’un des actifs centraux de l’activité. C’est peut-être bien la chose la plus précieuse que vous possédiez en dehors de vos relations clients.

Pourquoi une bibliothèque compte-t-elle davantage que les recettes prises une à une ? Parce qu’elle change votre façon d’aborder le travail nouveau. Quand une tâche arrive, votre premier geste n’est plus d’écrire un brief. C’est de consulter la bibliothèque. Souvent, une recette convient exactement, ou moyennant un petit changement. Vous remplissez les emplacements et l’envoyez. La tâche profite de chaque leçon intégrée à la recette, et vous consacrez votre attention aux parties réellement nouvelles.

Une bibliothèque a une forme naturelle. Les recettes se regroupent autour des activités principales de l’entreprise : relire le travail, le livrer, mener des recherches, rédiger des documents, entretenir les outils. Vous aurez peut-être une douzaine de recettes en tout, ou plusieurs dizaines, mais elles se répartissent généralement en quatre ou cinq familles. Les ranger par famille les rend plus faciles à trouver et vous montre où sont les trous. Si vous avez six recettes de rédaction et aucune recette de relecture, cela vous dit quelque chose sur l’endroit où vos exigences sont écrites et celui où elles n’existent que dans votre tête.

Une bibliothèque de bonnes recettes, c’est l’activité elle-même, mise par écrit.

Gardez la bibliothèque sous une forme simple et portable. Des fichiers texte dans un dossier, versionnés si possible, avec un court index qui liste chaque recette et dit quand l’utiliser. Les outils vont et viennent ; le texte brut survit. Si vos outils permettent de charger des recettes comme commandes ou skills, branchez-y la bibliothèque, bien sûr, mais gardez la source sous une forme que vous pourriez transférer demain vers un autre outil sans rien perdre.

Prenez soin de la bibliothèque comme de tout actif important. Quand une recette sert, notez si elle a marché. Quand elle pèche, corrigez-la aussitôt, pendant que le problème est frais. Quand deux recettes se recoupent, fusionnez-les. Quand une recette n’a pas servi depuis des mois, mettez-la aux archives. Une bibliothèque entretenue reste utile. Une bibliothèque qui ne fait que grossir devient un tiroir à bazar, et personne ne fouille un tiroir à bazar quand il est pressé.

Un dernier bénéfice mérite d’être nommé. Une bibliothèque de recettes est ce qui permet à quelqu’un d’autre de comprendre une activité menée par une seule personne. Si vous faites un jour appel à de l’aide, un collaborateur ou un prestataire, la bibliothèque est le moyen le plus rapide de lui montrer comment le travail se fait. C’est aussi ainsi que vous comprendrez votre propre activité au retour des vacances, quand vous aurez oublié la plupart des détails et devrez les reprendre rapidement. La bibliothèque se souvient à votre place.

Cette semaine, créez la bibliothèque si vous n’en avez pas : un dossier, un fichier d’index, et toutes les recettes que vous avez déjà, déplacées dedans. Classez-les par familles. Notez les trous. Puis, la prochaine fois qu’une tâche arrive, ouvrez d’abord la bibliothèque. Ce petit réflexe est le commencement d’une activité qui s’améliore d’elle-même.

La mémoire est une infrastructure

Les agents commencent la plupart des sessions sans rien savoir de vous. Ils ne se souviennent ni de la conversation d’hier, ni de la décision prise la semaine dernière, ni de la raison pour laquelle le script de build contient cette ligne étrange. Toute la continuité dont jouit votre activité, c’est à vous de la fournir. La mémoire, c’est-à-dire la trace écrite de ce que la machine devrait déjà savoir, n’est donc pas un agrément mais une infrastructure, au même titre que la plomberie. Personne ne l’admire. Sans elle, plus rien ne fonctionne.

La plupart des outils d’agents proposent désormais une forme de mémoire persistante : un fichier de projet que l’agent lit au début de chaque session, un stock de faits qu’il peut mettre à jour, des instructions qui s’appliquent à toutes les conversations d’un espace de travail. Les détails varient selon l’outil et continueront de changer. Ce qu’ils ont en commun, c’est l’idée que certaines connaissances doivent être chargées automatiquement, pour que vous n’ayez pas à les répéter dans chaque brief. Bien utilisée, c’est la plus grande amélioration de la qualité des agents à la portée d’un opérateur. Mal utilisée, c’est une source discrète de confusion.

Pensez la mémoire comme une pile de couches. Tout en bas, des fichiers texte brut : la forme la plus durable et la plus portable, lisible par n’importe quel outil et par vous. Au-dessus, les notes et les journaux : votre trace courante de ce qui s’est passé et pourquoi. Au-dessus encore, la mémoire de projet : l’ensemble choisi de faits et de règles que les agents de chaque projet chargent à chaque fois. Et au sommet, votre jugement, qui décide de ce qui entre dans chaque couche et de ce qui en sort. C’est dans la couche de mémoire de projet que se trouve l’essentiel du levier, parce que c’est ce que les agents voient réellement.

Ce que vous n’écrivez pas, vous l’expliquerez de nouveau. Et encore.

Traiter la mémoire comme une infrastructure modifie quelques habitudes. Vous lui accordez du temps d’entretien, au lieu de ne la mettre à jour que lorsque quelque chose tourne mal. Vous relisez ses modifications avec le même soin qu’une modification de code, car une mauvaise ligne en mémoire affecte toutes les sessions futures. Vous la gardez en texte brut autant que possible, car une infrastructure doit survivre aux outils construits par-dessus. Et vous la concevez pour ses lecteurs : les agents d’abord, et vous ensuite, quand vous revenez sur un projet après des mois d’absence.

Il y a aussi un changement de regard utile. Chaque fois que vous vous surprenez à expliquer deux fois la même chose à un agent, c’est un bug de mémoire. Le remède n’est pas de l’expliquer une troisième fois, mais de l’écrire dans la bonne couche pour que ce soit su désormais. Chaque fois qu’un agent commet une erreur parce qu’il ignorait quelque chose, c’est aussi un bug de mémoire. Collectionnez-les. Ce sont les bons de travaux de votre infrastructure de mémoire.

Cette semaine, prenez votre projet le plus actif et regardez ce que ses agents chargent au début d’une session. Si la réponse est « rien », commencez un fichier de mémoire. S’il en existe déjà un, lisez-le comme si vous étiez un nouvel agent, et marquez tout ce qui est faux, périmé ou manquant. Puis corrigez. Cela ressemblera à du ménage. C’est plus proche de la pose de canalisations, et l’eau coulera mieux pendant des mois.

Ce que l’agent devrait déjà savoir

Un fichier de mémoire de projet est un court document qu’un agent lit au début de chaque session dans ce projet. Son rôle est de répondre à l’avance aux questions que poserait n’importe quel nouveau venu compétent dès son premier matin. À quoi sert ce projet ? Comment le compile-t-on, le teste-t-on, le lance-t-on ? Quelles sont les règles ici ? Où sont les pièges ? Si ces quatre questions trouvent de bonnes réponses, la plupart des sessions démarrent au bon endroit sans que vous ayez à dire quoi que ce soit.

Commencez par la raison d’être. Une ou deux phrases sur ce qu’est le projet et à qui il sert. Cela paraît superflu, puisque l’agent peut lire le code, mais le code dit ce que fait une chose, pas à quoi elle sert. Savoir qu’un outil sert une poignée d’utilisateurs internes plutôt que le grand public change une foule de petites décisions, des messages d’erreur au soin apporté aux performances.

Ensuite, les commandes. Les commandes exactes pour installer, compiler, tester, analyser et lancer le projet, et tout ce qu’elles ont d’inhabituel. C’est la partie la plus utile en pratique, car sans elle les agents devinent, et les commandes devinées sont une source fréquente de temps perdu. Si la suite de tests exige une variable d’environnement particulière ou une base de données en marche, dites-le ici.

Ensuite, les règles. Les conventions qui ne se lisent pas dans le code : comment on nomme les choses, où vont les nouveaux fichiers, quel est le style maison à l’écrit, quels motifs sont préférés et lesquels sont en voie d’abandon. Limitez-vous à celles qui comptent vraiment et qu’un agent risquerait plausiblement de rater. Un fichier de mémoire comptant cinquante règles n’est pas mieux suivi qu’un fichier qui en compte dix. Il l’est généralement moins bien, parce que les règles importantes sont diluées dans les triviales.

Le fichier de mémoire, c’est l’accueil que vous offrez à chaque nouvelle recrue, chaque matin, gratuitement.

Enfin, les pièges. Les endroits où les choses tournent mal : le module fragile, le nom de fonction trompeur, le test capricieux le mardi, le dossier qui a l’air inutilisé et ne l’est pas. C’est sur les pièges que la mémoire se rembourse le plus clairement, car chacun prévient une erreur précise et récurrente. Beaucoup des meilleures lignes d’un fichier de mémoire mûr ont commencé comme une note dans un compte rendu d’incident.

Gardez le fichier court. Une page ou deux suffisent largement pour la plupart des projets. Les agents le lisent en entier à chaque session, si bien que tout ce qu’il contient coûte un peu d’attention à chaque fois, et qu’un contenu hors sujet peut pousser le travail dans des directions bizarres. Si le fichier s’allonge, scindez-le : un fichier central toujours chargé, et des fichiers thématiques vers lesquels on renvoie quand c’est pertinent. Beaucoup d’outils gèrent directement ce genre de découpage.

Écrivez-le en phrases simples et directes, dans le même registre qu’un bon brief. Évitez les déclarations d’intention que personne ne peut vérifier, comme écrire du code de haute qualité. Préférez des formules précises, comme chaque nouvelle fonction a un test dans le fichier correspondant sous tests/. L’agent peut suivre la seconde. Devant la première, il ne peut qu’acquiescer poliment.

Cette semaine, écrivez ou réécrivez le fichier de mémoire d’un projet selon les quatre rubriques : raison d’être, commandes, règles, pièges. Restez sous les deux pages. Puis lancez une nouvelle session et observez combien vous avez moins à expliquer. Ce silence, c’est le fichier qui fait son travail.

Le carnet de l’opérateur

Les fichiers de mémoire de projet sont pour les agents. Il vous faut aussi quelque chose pour vous : un carnet courant dans lequel vous notez ce que vous avez fait, ce que vous avez remarqué et ce à quoi vous réfléchissez. C’est l’outil le moins prestigieux de la panoplie de l’opérateur et l’un des plus puissants, car c’est le seul endroit où toute l’activité, tous projets confondus, est visible en un seul flux.

Le format compte moins que l’habitude. Un unique fichier texte avec un intitulé daté pour chaque jour fonctionne parfaitement. Un carnet papier aussi, si vous préférez. Ce qui compte, c’est qu’il n’y en ait qu’un, que vous y écriviez chaque jour ouvré, et que vous puissiez le fouiller ou le parcourir plus tard. Beaucoup d’opérateurs le gardent ouvert toute la journée et griffonnent une ligne dès qu’il se passe quelque chose : une décision prise, une surprise rencontrée, une idée mise de côté, un fil lancé ou terminé.

Qu’y met-on ? Surtout des lignes courtes. Correctif de l’importateur livré ; lignes vides désormais gérées. L’agent revenait sans cesse à l’ancienne config ; ajouté une note en mémoire. Le client veut le rapport une semaine plus tôt ; avancé. Idée : condensé hebdomadaire des fils en retard ; en file. Rien de tout cela n’est de la littérature. Ensemble, ces lignes forment une trace de l’activité extrêmement utile, d’une manière que vous ne pouvez pas prévoir au moment où vous les écrivez.

Le carnet ne se souvient pas pour vous. Il se souvient à votre place.

Le carnet mérite sa place de trois façons. D’abord, il nourrit la clôture et la revue. En fin de journée, parcourir les entrées du jour vous dit ce qui a été livré et ce qui reste ouvert bien plus vite que de le reconstituer à partir des fils. Ensuite, il nourrit les revues hebdomadaires et trimestrielles, dont traite une partie ultérieure du livre. Relire une semaine d’entrées fait apparaître des motifs invisibles au jour le jour : le projet qui n’arrête pas de caler, le type de tâche qui tourne toujours mal, l’heure de la journée où rien de bon n’arrive. Enfin, c’est une trace dans laquelle chercher quand quelque chose revient sur le tapis. Quand un client demande pourquoi une modification a été faite en mars, le carnet a souvent la réponse en une ligne.

La chaîne qui compte est : le noter, le relire, décider. Un carnet écrit mais jamais relu est un journal intime. Utile peut-être, mais pas un outil d’exploitation. Intégrez la relecture à votre rythme : un survol à chaque clôture, une vraie lecture à chaque revue hebdomadaire. Chaque lecture devrait se conclure par au moins une décision, même si ce n’est que ajouter ce piège au fichier de mémoire ou arrêter de lancer des fils après seize heures.

Les agents peuvent aider ici aussi, mais avec précaution. Un agent peut résumer une semaine d’entrées, en extraire les thèmes récurrents ou rédiger une liste des points ouverts. C’est utile. Ce qu’un agent ne devrait pas faire, c’est tenir le carnet à votre place, car l’acte d’écrire une ligne est en soi un petit moment de réflexion, et ce moment fait partie de la valeur.

Cette semaine, commencez le carnet si vous n’en avez pas. Un fichier, un intitulé par jour, une ligne par chose qui s’est passée. À la clôture du vendredi, lisez les entrées de la semaine de haut en bas et écrivez une décision tout en bas. C’est toute la pratique. Elle porte ses fruits en silence, comme le font les bonnes habitudes.

Un journal des décisions

Les décisions sont ce qu’un opérateur produit de plus précieux et ce qu’il a le moins de chances de consigner. Le code est versionné. Les documents sont enregistrés. Les pull requests ont des descriptions. Mais les raisons qui les sous-tendent, pourquoi cette approche plutôt que l’autre, pourquoi ce projet plutôt que celui-là, pourquoi on a abandonné la fonctionnalité, ne vivent généralement que dans votre tête, où elles se décomposent à une vitesse alarmante. Trois mois plus tard, vous regardez quelque chose et vous ne vous rappelez sincèrement plus pourquoi c’est ainsi.

Un journal des décisions règle cela à peu de frais. C’est un fichier unique, par projet ou pour toute l’activité, dans lequel vous consignez les décisions importantes au moment où vous les prenez. Chaque entrée est courte : la date, la décision en une phrase, la raison en une ou deux, et la principale alternative écartée. C’est tout. Quelques lignes qui vous feront gagner des heures.

Pourquoi consigner l’alternative écartée ? Parce que c’est la partie dont vous aurez le plus besoin plus tard. Quand vous, ou un agent, revenez sur une décision, la première question est généralement pourquoi n’a-t-on pas simplement fait l’autre chose, l’évidente ? Si le journal dit envisagé le service de recherche hébergé ; écarté car les résultats devaient fonctionner hors ligne, la question trouve sa réponse en quelques secondes et le vieux débat n’a pas à être rouvert. Sans cette ligne, vous risquez fort de passer un après-midi à redécouvrir la raison, ou pire, d’inverser la décision sans vous souvenir qu’il y en avait une.

Noter ce qu’on a décidé est utile. Noter pourquoi, c’est ce qui vous sauve.

Qu’est-ce qui compte comme important ? Un test grossier consiste à se demander si quelqu’un pourrait raisonnablement poser la question plus tard. Choix d’architecture, changements de périmètre, abandon ou mise en sommeil d’un projet, choix d’un outil, changement d’une norme, acceptation d’un risque connu. Les petits choix du quotidien n’ont pas besoin d’entrée ; c’est à cela que sert le carnet. Si vous consignez plus de quelques décisions par projet et par semaine, vous en consignez probablement trop.

Le journal des décisions aide aussi les agents. S’il vit à côté du projet, vous pouvez y renvoyer les agents quand ils travaillent sur quelque chose qu’une décision antérieure concerne, ou en inclure un court résumé dans la mémoire du projet. Un agent qui sait que le service de recherche a été écarté pour des raisons de fonctionnement hors ligne ne le suggérera pas de nouveau, et ne le réintroduira pas en douce en corrigeant autre chose. C’est l’un des rares endroits où donner de l’histoire aux agents, plutôt que le seul état présent, améliore réellement leur travail.

Un bénéfice supplémentaire passe facilement inaperçu. Écrire la raison vous oblige à en avoir une. Les opérateurs découvrent parfois, au moment de consigner une décision, que leur raisonnement est plus mince qu’ils ne le pensaient. Ce n’est pas une raison pour cesser de tenir le journal. C’est le journal qui fait son travail le plus utile, avant que la décision n’ait eu la moindre conséquence.

Cette semaine, ouvrez un journal des décisions pour votre projet le plus chargé. Rattrapez les trois décisions les plus importantes dont vous vous souvenez pour le mois écoulé, avec leurs raisons et les alternatives écartées. Puis ajoutez des entrées à mesure que de nouvelles décisions arrivent. Dans trois mois, quand quelqu’un demandera pourquoi, vous aurez le plaisir peu commun de savoir, tout simplement.

Des notes qu’on relit

Les opérateurs écrivent énormément : briefs, notes de passation, fichiers de mémoire, entrées de carnet, journaux de décisions, comptes rendus d’incident. La question qui compte à propos de tout cela n’est pas combien a été écrit, mais combien a été relu, et quelle part de ce qui a été relu a conduit à une meilleure décision. Représentez-vous un entonnoir. Beaucoup entre par le haut. Moins est relu. Moins encore change quoi que ce soit. Le but n’est pas forcément d’écrire moins, mais de rétrécir l’entonnoir en haut et de l’élargir en bas : moins de notes, et davantage qui servent.

Les notes qu’on relit ont quelques points communs. Elles sont écrites pour un lecteur précis à un moment précis : la revue de demain matin, la prochaine session sur ce projet, un agent qui commence à travailler, vous dans trois mois. Savoir qui lira et quand change ce qu’on écrit. Une note de passation pour demain peut être laconique. Une entrée du journal des décisions destinée à être lue dans trois mois doit expliciter ses raisons, car d’ici là le contexte se sera évaporé.

Elles commencent par la conclusion. La ligne la plus importante est la première : quel est l’état, qu’a-t-on décidé, que faut-il faire. Le détail suit, pour qui en a besoin. Les notes qui commencent par un récit et finissent par l’essentiel sont rarement lues jusqu’au bout, ce qui veut dire que l’essentiel n’est presque jamais lu.

Écrivez la note pour la personne fatiguée qui la lira. Cette personne, c’est généralement vous.

Elles sont à un endroit prévisible. Une note introuvable n’existe pas. Décidez où vit chaque type de note, le carnet dans un fichier, les passations en tête de la mémoire de projet, les décisions dans le journal, et tenez-vous-y. S’il faut chercher une note, souvent on ne se donnera pas la peine, et la note aura été écrite pour rien.

Elles sont courtes. Les notes longues sont survolées, et les notes survolées perdent leurs détails. Si une note doit être longue, donnez-lui en tête un résumé d’une ligne qui puisse tenir seul. Beaucoup d’opérateurs adoptent une règle simple : aucune note de plus d’un écran sans ligne de résumé.

Et elles sont élaguées. Une note de passation dépassée doit être supprimée ou marquée comme ancienne, sinon le lecteur suivant agira sur une information périmée. Un fichier de mémoire plein de conseils obsolètes est pire qu’un fichier court aux conseils actuels. Le chapitre suivant traite l’élagage plus en détail, mais il a sa place ici aussi, car les notes jamais élaguées sont des notes auxquelles on finit par ne plus faire confiance.

Il existe un moyen de tester vos notes. Une fois par semaine, choisissez une note écrite il y a au moins quinze jours et lisez-la à froid. Demandez-vous si elle vous a appris rapidement ce que vous aviez besoin de savoir, si quelque chose y était faux ou périmé, et si elle vous a conduit à faire quoi que ce soit. Si la réponse est bonne sur les trois points, continuez à écrire ce genre de note. Sinon, ajustez.

Cette semaine, regardez les dix dernières notes que vous avez écrites, de quelque nature que ce soit, et demandez-vous pour chacune : pour qui était-elle, et l’a-t-il lue ? Si vous ne savez pas répondre, la note a probablement été écrite pour personne. Écrivez-en moins de cette sorte, et davantage pour quelqu’un en particulier.

Élaguer la mémoire

La mémoire s’accumule. Chaque fois qu’un agent se trompe, vous ajoutez une règle. Chaque fois qu’une nouvelle convention émerge, vous la notez. Chaque fois qu’un piège mord, vous le consignez. Tout cela est de bonne pratique, et rien n’en est jamais retiré, parce que retirer paraît risqué et ajouter paraît responsable. Au bout de six mois, le fichier de mémoire est trois fois plus long qu’au départ, un tiers en est périmé, et les agents suivent des instructions écrites pour un projet qui n’existe plus tout à fait.

Une mémoire périmée est pire que pas de mémoire du tout. Un agent sans mémoire pose des questions ou explore. Un agent à la mémoire périmée agit avec assurance sur des informations fausses. Il utilise l’ancienne commande, suit la convention abandonnée, contourne de façon inutilement compliquée le piège corrigé il y a des mois. Les erreurs sont subtiles parce qu’elles ressemblent à des choix délibérés, et en un sens elles en sont : c’étaient vos choix délibérés, autrefois.

Le remède est un cycle : ajouter, revoir, élaguer. L’ajout se fait naturellement au fil du travail. La revue et l’élagage doivent être planifiés, car ils n’auront jamais lieu spontanément. Une fois par mois, ou au minimum à chaque revue trimestrielle, lisez intégralement chaque fichier de mémoire, stylo rouge en tête. Pour chaque ligne, demandez-vous si elle est encore vraie, si elle est encore nécessaire, et si elle est au bon endroit.

Une mémoire qui ne fait que grossir devient un musée. Les agents devraient travailler dans un atelier.

Certaines lignes seront tout simplement fausses : commandes modifiées, fichiers déplacés, règles abandonnées. Corrigez-les ou supprimez-les. D’autres seront vraies mais plus nécessaires : un piège corrigé à la source, une convention désormais imposée par l’outillage. Supprimez-les ; l’outillage se souvient à votre place. D’autres encore seront vraies et nécessaires mais mal placées : une règle propre à un projet dans un fichier général, ou une consigne ponctuelle promue en consigne permanente. Déplacez-les.

Une astuce utile consiste à demander l’aide d’un agent. Donnez-lui le fichier de mémoire et l’état actuel du projet, et demandez-lui d’identifier les lignes qui semblent périmées, contradictoires ou démenties par ce qu’il peut voir. Il ne repérera pas tout, et il signalera quelques lignes qui sont en fait très bien, mais c’est une bonne première passe, particulièrement douée pour repérer les contradictions entre des règles écrites à des mois d’écart.

L’élagage garde aussi la mémoire courte, ce qui compte en soi. Chaque ligne d’un fichier de mémoire est lue par chaque session. Un fichier élagué jusqu’à sa moitié essentielle n’est pas seulement plus exact mais plus efficace, car les règles restantes ne se disputent plus l’attention avec des règles mortes.

Cette semaine, prenez votre plus gros fichier de mémoire et élaguez-le. Visez à en retirer au moins un cinquième. Lisez chaque ligne, supprimez ce qui est faux ou superflu, déplacez ce qui est mal placé. Puis menez une session normale et voyez si quelque chose tourne mal. Dans la plupart des cas, rien ne tournera mal, et vous aurez appris une chose utile : une bonne partie de ce que vous transportiez était du poids, pas du savoir.

Une seule source de vérité

Chaque fait de votre activité devrait avoir exactement un domicile. La commande de test vit à un endroit. Le style maison vit à un endroit. L’état actuel de chaque projet vit à un endroit. Quand un fait vit à deux endroits, les deux copies finiront par diverger, et quand elles divergeront, vous et vos agents perdrez du temps à déterminer laquelle a raison. Souvent, vous ne remarquerez même pas la divergence avant que quelque chose tourne mal à cause d’elle.

La duplication s’installe pour des raisons innocentes. Vous mettez les instructions de build dans le fichier de mémoire pour l’agent et dans le readme pour les humains. Vous tenez une liste de projets dans votre carnet et une autre dans un tableur. Vous notez une décision dans le journal des décisions et aussi dans la description de la pull request, puis vous mettez à jour l’une et pas l’autre. Chaque copie était utile au moment où on l’a faite. L’ennui, c’est que les faits changent, et que vous ne mettrez jamais à jour que la copie que vous avez sous les yeux.

Le remède consiste à choisir un domicile pour chaque type de fait et à pointer vers lui depuis partout ailleurs. Le fichier de mémoire dit voir le readme pour les commandes de build au lieu de les répéter, ou le readme dit voir le fichier de mémoire, selon celui que vous entretenez le plus soigneusement. Le registre des projets est l’unique endroit où vit l’état des projets ; tout le reste y renvoie. Le journal des décisions est l’endroit où les décisions sont consignées ; la description de la pull request renvoie à l’entrée du journal.

Deux copies d’un fait, c’est un fait et un futur bug.

Pointer a un coût : le lecteur doit suivre le pointeur. Pour les agents, ce coût est généralement minuscule ; ils ouvrent un fichier en un instant. Pour vous, il est un peu plus élevé, mais bien moindre que le coût d’agir sur une copie périmée. La seule vraie exception est le court résumé d’une chose qui vit ailleurs, qu’il vaut parfois la peine de garder par commodité. Si vous en gardez un, étiquetez-le clairement comme résumé et indiquez où se trouve la source, pour que quiconque a un doute sache à quoi se fier.

Une source unique de vérité compte particulièrement dans un monde peuplé de nombreux agents. Si trois fils travaillent sur le même projet et que chacun a une idée légèrement différente des conventions, parce qu’ils ont été briefés à partir de copies légèrement différentes, vous obtiendrez trois genres de travail légèrement différents. Rassembler les conventions dans un fichier de mémoire unique que chaque fil charge est le moyen le plus simple de faire se comporter la flotte de façon cohérente.

Cela compte aussi pour vous, car la duplication taxe votre mémoire autant que celle des agents. S’il faut vous rappeler que l’état est dans le carnet, et aussi dans le registre, et aussi dans le tableur, vous en oublierez un. Si l’état n’est que dans le registre, il n’y a rien à retenir, sinon l’endroit où se trouve le registre.

Cette semaine, choisissez un fait dont vous savez qu’il est écrit à plus d’un endroit et consolidez-le. Choisissez son domicile, mettez-le à jour, et remplacez les autres copies par des pointeurs. Puis faites de même pour un autre la semaine prochaine. C’est du rangement sans gloire, et il élimine de l’activité toute une catégorie de confusion, définitivement.

Les secrets restent dehors

Fichiers de mémoire, carnets, briefs et journaux sont conçus pour être lus largement. Les agents les lisent à chaque session. Ils sont commités dans des dépôts, synchronisés vers un stockage en ligne, collés dans des fils et parfois partagés avec des collaborateurs. C’est exactement ce qui les rend utiles, et exactement pourquoi ils ne doivent jamais contenir de secrets. La mémoire n’est pas un coffre-fort.

Par secrets, entendez large. Les mots de passe et les clés d’accès, évidemment. Mais aussi les jetons, les chaînes de connexion privées, les données personnelles concernant clients ou utilisateurs, tout ce qui relève d’un accord de confidentialité, et tout ce que vous seriez gêné de voir apparaître dans un résultat de recherche public. La règle est simple : si cela causerait du tort entre de mauvaises mains, cela ne va dans rien de ce qu’un agent lit par défaut.

Une façon utile d’aborder n’importe quelle information consiste à la placer sur deux axes. L’un est la sensibilité : combien de tort causerait son exposition. L’autre est la portée : dans combien d’endroits et sous combien d’yeux elle finira. Les fichiers de mémoire et les briefs ont une portée très élevée. Tout élément sensible qui atterrit dans un document à forte portée est dans le mauvais quadrant. Tenez-le à l’écart, et placez-le plutôt dans un endroit conçu pour les données sensibles.

Si l’agent peut le lire chaque matin, partez du principe que le monde pourra le lire un jour.

Les alternatives pratiques sont bien établies. Les identifiants ont leur place dans un vrai gestionnaire de secrets, dans des variables d’environnement ou dans la gestion des secrets que fournissent vos outils, et les agents y ont accès par ces mécanismes, jamais en collant la valeur dans un brief. Les données personnelles des clients ont leur place dans le système que vous utilisez pour les dossiers clients, et quand un agent doit travailler avec, il ne doit recevoir que le minimum nécessaire à la tâche. Les documents confidentiels se désignent par leur emplacement plutôt que de se copier : les conditions du contrat sont dans le dossier du client plutôt que les conditions elles-mêmes.

Il vaut aussi la peine de réfléchir à ce que les agents pourraient écrire d’eux-mêmes en mémoire. Certains outils permettent aux agents d’enregistrer des faits appris pendant une session. C’est utile, mais cela signifie qu’une valeur aperçue une fois pendant un débogage pourrait être enregistrée à jamais. Revoyez périodiquement la mémoire automatique, et ajoutez une consigne permanente selon laquelle les agents ne doivent jamais stocker d’identifiants, de jetons ou de données personnelles dans la mémoire ou les notes. La plupart des agents la respecteront fidèlement une fois prévenus. Certains auront besoin de rappels.

Si un secret finit tout de même là où il ne devrait pas être, traitez-le comme un incident, pas comme du rangement. Changez l’identifiant au lieu de vous contenter d’effacer la ligne, car un secret passé par un dépôt ou un fichier synchronisé doit être présumé vu. Puis rédigez une courte note d’incident et ajoutez le garde-fou qui l’aurait empêché. Le même principe revient dans le chapitre sur l’interdiction de commiter des secrets, car c’est l’une des très rares règles de ce livre qui ne souffre aucune exception.

Cette semaine, fouillez chaque fichier de mémoire, carnet et recette en votre possession à la recherche de tout ce qui ressemble à une clé, un mot de passe, un jeton ou les données personnelles de quelqu’un. Retirez ce que vous trouvez et changez tout ce qui était un identifiant actif. Puis ajoutez la consigne permanente à votre mémoire. Cela prend une demi-heure et ferme une porte qui, sinon, resterait discrètement ouverte.

Les passations entre sessions

Chaque session se termine et, pour tout travail un tant soit peu conséquent, une autre session le reprendra plus tard. Ce peut être vous demain, un nouveau fil d’agent, ou un fil parallèle qui doit savoir ce que celui-ci a fait. La qualité de cette reprise dépend presque entièrement d’un petit document : la passation. Écrivez-la bien, et la session suivante démarre en quelques minutes. Sautez-la, et la session suivante démarre par de l’archéologie.

Une bonne passation répond à quatre questions. Quel était le but de cette session ? Quel est l’état actuel, précisément, y compris ce qui est fini et ce qui ne l’est pas ? Quel est le geste suivant ? Et que doit savoir la session suivante qu’elle ne découvrirait pas autrement : une impasse déjà explorée, une décision prise, une surprise rencontrée ? Quatre courts paragraphes, ou quatre lignes, selon la taille du travail.

La plus importante des quatre est le geste suivant. Une passation qui décrit magnifiquement l’état mais ne dit pas quoi faire ensuite laisse la session suivante le déterminer, ce qui fait perdre du temps et risque d’aboutir à une autre conclusion. Suite : ajouter le test du cas vide, puis lancer la suite complète vaut plus qu’une page de description, car cela permet à la session suivante de passer à l’action immédiatement.

La meilleure passation est celle qui permet à la session suivante de commencer par un verbe.

La deuxième en importance, ce sont les impasses. Les agents, comme les gens, ont tendance à redécouvrir le même mauvais chemin. Si cette session a passé une demi-heure à découvrir que la correction évidente ne marche pas à cause d’une contrainte cachée, dites-le dans la passation. Sinon, la session suivante passera sa propre demi-heure à faire la même découverte, et n’arrivera peut-être même pas à la même conclusion.

Où vit la passation ? Là où la session suivante regardera sans qu’on le lui dise. Pour beaucoup d’opérateurs, c’est une courte section en tête du fichier de mémoire du projet, remplacée à la fin de chaque session. Pour d’autres, c’est une note dans le registre des projets à côté de la ligne du projet. Pour le travail dans un dépôt, ce peut être la description de la pull request, mise à jour à mesure que le travail avance. L’emplacement compte moins que la constance : choisissez-en un et utilisez-le toujours.

Les agents sont doués pour rédiger des passations, et vous devriez les laisser faire. À la fin d’une session, demandez à l’agent d’écrire la passation selon les quatre questions. Puis lisez-la et corrigez-la. L’étape de correction n’est pas facultative. Les agents ont tendance à être optimistes sur l’état des choses, décrivant comme presque fini ce qui est à moitié fait, et ils ne savent pas toujours lesquelles de leurs découvertes compteront plus tard. C’est votre correction qui rend la passation fiable.

Cette semaine, terminez chaque session d’un travail en plusieurs sessions par une passation en quatre questions. Placez-la toujours au même endroit. Puis observez comment se passe la session suivante. Vous constaterez probablement que les dix premières minutes, autrefois passées à chercher où en étaient les choses, sont désormais passées à faire les choses. La passation est une petite politesse envers votre futur vous, et votre futur vous est un client exigeant.

L’esprit classeur

Une idée en vogue veut que la solution à la surcharge d’information soit un second cerveau : un vaste système de connaissances personnel, maillé, étiqueté avec amour, dans lequel tout ce que vous avez jamais lu ou pensé est stocké pour plus tard. Certaines personnes en construisent un et le trouvent sincèrement utile. Bien plus nombreuses sont celles qui en construisent un et découvrent qu’elles ont créé de magnifiques archives qu’elles ne consultent jamais. Pour un opérateur, un modèle plus humble convient mieux : non pas un second cerveau, mais un classeur à tiroirs.

La différence tient à ce qu’on optimise. Un second cerveau optimise la capture : tout faire entrer, tout relier, tout enrichir. Un classeur optimise la récupération : pouvoir mettre la main sur la bonne chose au bon moment. La capture sans récupération, c’est de l’accumulation compulsive. La récupération sans capture est impossible. Ce que vous voulez, c’est l’intersection : l’information capturée que vous pouvez réellement retrouver et utiliser quand vous en avez besoin. Cette intersection est généralement bien plus petite que les archives.

Les opérateurs équipés d’agents ont une raison particulière de privilégier la récupération. Les agents sont excellents pour chercher, lire et résumer, ce qui signifie que des fichiers simples et bien organisés sont aujourd’hui considérablement plus utiles qu’autrefois. Inutile d’étiqueter et de relier tout à la main si un agent peut fouiller le dossier et en extraire ce qui est pertinent. Ce qu’il faut, en revanche, c’est que les fichiers soient à des endroits prévisibles, nommés de façon sensée et écrits assez clairement pour qu’une recherche les trouve.

Une note introuvable est une note que vous n’avez pas écrite.

Gardez donc le classeur simple. Un petit nombre de dossiers de premier niveau qui correspondent à votre façon de penser votre travail : projets, recettes, décisions, références, archives. Dans chaque dossier de projet, les mêmes quelques fichiers à chaque fois : mémoire, entrée du registre, journal des décisions, passations. Des noms qu’une recherche trouvera. Du texte brut partout où c’est possible. Et une ferme habitude d’archiver ce qui est terminé, pour que les tiroirs actifs ne contiennent que ce qui est actif.

Capturez avec discernement. Tout n’a pas besoin d’être gardé. Un test utile consiste à se demander si l’on peut imaginer un moment futur précis où l’on voudra cette chose : une question de client, une tâche récurrente, une décision à réexaminer. Si oui, classez-la là où ce moment ira chercher. Sinon, laissez-la partir. La peur de perdre quelque chose est réelle, mais la plupart de ce que les opérateurs conservent n’est jamais rouvert, et le fouillis qui en résulte rend les choses utiles plus difficiles à trouver.

La récupération s’améliore avec la pratique. Quand vous avez besoin de quelque chose, essayez de le trouver avant de demander à un agent de chercher. Remarquez où vous avez regardé en premier. C’est là que votre esprit s’attend à le trouver, et si c’était ailleurs, envisagez de le déplacer. Avec le temps, le classeur se remodèle autour de votre façon réelle de penser, qui est le seul système de classement qui fonctionne de manière fiable.

Cette semaine, demandez à un agent de trouver dans vos fichiers trois choses dont vous savez qu’elles existent : une décision du trimestre dernier, une recette que vous utilisez rarement, une vieille note sur un client. Chronométrez chaque recherche. Là où elle a été lente ou a échoué, demandez-vous pourquoi, et corrigez le classement. Vous ne construisez pas un cerveau. Vous construisez un classeur qui s’ouvre au bon tiroir, ce qui est une chose bien plus accessible.

Le registre des projets

Un opérateur équipé d’agents peut avoir un nombre remarquable de choses en cours. Un projet client, deux outils internes, un brouillon de livre, une question de recherche, une migration terminée à quatre-vingt-dix pour cent depuis trois semaines, une idée commencée un dimanche. Chacune peut avoir plusieurs fils qui tournent en parallèle. Sans un endroit unique qui recense tout cela, l’activité devient impossible à voir dans son ensemble, et ce qu’on ne voit pas dans son ensemble, on ne peut pas le piloter.

Cet endroit unique, c’est le registre des projets. C’est la liste de chaque projet actuellement présent dans votre vie, avec une ligne pour chacun, un statut et un geste suivant. Ce n’est ni un logiciel de gestion de projet, ni un gestionnaire de tâches, ni un tableau kanban, même s’il peut vivre dans n’importe lequel de ces outils si vous le souhaitez. C’est la vue d’ensemble : la réponse à la question qu’est-ce que je fais réellement tourner ?

Le registre se trouve au sommet d’une petite hiérarchie. En dessous, les projets, une ligne chacun. Chaque ligne indique un geste suivant, la chose la plus importante qui doit se produire sur ce projet. Et en dessous encore, les fils et les sessions qui font le travail effectif. Le registre est la partie que vous regardez chaque matin. Les fils sont la partie que regardent les agents. Garder ces deux niveaux séparés est ce qui vous permet de penser l’activité sans vous noyer dans ses détails.

S’il n’est pas au registre, ce n’est pas un projet. C’est une distraction qui a de l’ambition.

Qu’est-ce qui va au registre ? Tout ce qui demandera plus d’une session, implique un engagement envers quelqu’un ou produira quelque chose qui sera livré. Les tâches ponctuelles n’y ont pas leur place ; elles vont dans les trois du jour ou dans la file. Les responsabilités permanentes, comme maintenir un outil à jour, peuvent figurer au registre comme projets permanents, avec leur propre statut simple.

Gardez-le à un seul endroit, en texte brut si possible, et assez court pour être lu en une minute. Beaucoup d’opérateurs le tiennent dans un fichier unique, avec un intitulé par statut et une ligne par projet. Certains le tiennent sous forme de tableau. Quelques-uns le gardent sur papier, à côté du bureau. Le format compte bien moins que la discipline consistant à n’avoir qu’un seul registre et à le mettre à jour à chaque clôture.

Le registre remplit trois fonctions à la fois. Il nourrit la revue du matin, puisque les trois du jour y sont choisis. Il vous garde honnête sur votre capacité, puisque le nombre de lignes actives est une mesure visible de ce que vous avez entrepris. Et il vous montre ce qui dérive, car une ligne dont le geste suivant n’a pas changé depuis quinze jours est une ligne qui a besoin d’une décision, pas de davantage de travail.

Il permet aussi aux agents d’aider à la supervision. Un agent peut lire le registre à côté des fils et vous dire quels projets n’ont connu aucune activité cette semaine, quels gestes suivants sont périmés et quels fils ne sont rattachés à aucun projet. C’est un condensé matinal utile, tant que le registre lui-même reste à vous de le modifier.

Cette semaine, écrivez votre registre. Chaque projet, une ligne, un statut et un geste suivant. La longueur de la liste vous surprendra peut-être. Cette surprise est la première chose utile que le registre vous apprendra.

Une ligne par projet

Le registre ne fonctionne que si chaque projet tient sur une ligne. On dirait une règle de mise en forme. C’est en réalité une règle de pensée, car comprimer un projet en une seule ligne vous oblige à savoir quel est son état et ce qui doit se passer ensuite. Si vous ne pouvez pas écrire la ligne, c’est que vous ne comprenez pas assez bien le projet à l’heure actuelle pour le piloter.

Une bonne ligne comporte quatre éléments : le nom du projet, son statut, son geste suivant et, s’il y a lieu, une date. Réécriture de l’importateur : actif ; suite, livrer le correctif des lignes vides ; d’ici jeudi. Rapport client : en attente ; suite, relancer pour les retours sur la version deux. Plan de formation : en sommeil ; suite, revoir à la revue trimestrielle. Chaque ligne est une phrase que vous pourriez prononcer en moins de cinq secondes, et chacune vous dit exactement quoi faire si vous choisissiez de travailler sur ce projet maintenant.

C’est dans la compression que réside la valeur. Chaque projet traîne derrière lui bien plus d’informations qu’une ligne ne peut en contenir : historique, contexte, questions ouvertes, risques, idées. Tout cela a sa place quelque part, dans le fichier de mémoire du projet, son journal des décisions ou ses notes de passation. La ligne du registre n’en est pas le résumé. Elle en est la distillation de ce qui compte pour piloter : où en est-il, et quelle est la suite ?

Si vous ne pouvez pas le dire en une ligne, c’est que vous ne le savez pas encore.

Écrire le geste suivant est la partie la plus difficile, et la plus utile. Ce doit être une action concrète, pas un thème. Travailler sur l’importateur est un thème. Livrer le correctif des lignes vides est un geste. Réfléchir aux tarifs est un thème. Rédiger deux options de tarifs et en choisir une est un geste. Les thèmes ne vous disent pas quoi faire ce matin. Les gestes, si, et c’est pourquoi on peut piloter une journée à partir d’un registre de gestes, tandis qu’un registre de thèmes n’est qu’une liste de soucis.

Quand la ligne d’un projet est difficile à écrire, prenez-le au sérieux. Cela signifie généralement l’une de trois choses. Le projet en recouvre en réalité plusieurs et devrait être scindé en plusieurs lignes. Le projet attend une décision que vous n’avez pas prise, auquel cas le geste suivant est de la prendre. Ou le projet a perdu sa raison d’être et continue par habitude, auquel cas le geste suivant est peut-être de le mettre en sommeil ou d’y mettre fin. Les trois méritent d’être sus.

Les agents peuvent rédiger les lignes du registre à partir des notes de passation d’un projet, et c’est un raccourci pratique à la clôture. Mais retouchez chaque ligne vous-même. Le geste suivant, en particulier, est une décision, et les agents sont enclins à proposer la suite la plus évidente plutôt que la plus précieuse. Parfois, le geste suivant le plus précieux est de s’arrêter, et un agent le suggère rarement de lui-même.

Cette semaine, réécrivez chaque ligne de votre registre sous la forme en quatre éléments : nom, statut, geste suivant, date. Là où le geste suivant est un thème, transformez-le en action. Là où une ligne refuse de se comprimer, cherchez pourquoi. À la fin, vous devriez pouvoir lire tout le registre à voix haute en moins d’une minute et savoir exactement ce dont chaque projet a besoin. C’est le registre qui fait son travail.

Des statuts qui veulent dire quelque chose

Chaque projet du registre a un statut, et le vocabulaire que vous employez pour les statuts compte plus qu’on ne le croirait. Trop de mots de statut, et ils se confondent : en cours, en route, engagé, démarré, en développement. Trop peu, et ils masquent des différences importantes. Ce qu’il vous faut, c’est un vocabulaire réduit et honnête, dans lequel chaque mot implique une action précise, et l’ensemble le plus utile pour la plupart des opérateurs tient en quatre mots : idée, actif, en sommeil et fini.

Une idée est une chose que vous pourriez faire mais à laquelle vous ne vous êtes pas engagé. Elle figure au registre, ou plus souvent sur une liste à part, pour ne pas se perdre, mais on n’attend rien d’elle. Les idées ne coûtent pas cher et doivent le rester. Le danger, avec les agents, c’est que les idées deviennent actives par accident : vous lancez un fil pour explorer quelque chose, le fil produit quelque chose de prometteur, et soudain existe un projet que vous n’avez jamais décidé de lancer. Tenez une frontière ferme entre idée et actif, et ne la franchissez qu’exprès.

Actif signifie que vous vous y êtes engagé et qu’il reçoit de l’attention cette semaine. Les projets actifs ont un geste suivant en cours de traitement, et ils concourent pour les trois du jour. Le nombre de projets actifs est le chiffre le plus important du registre, car c’est ce qui se rapproche le plus d’une mesure de votre charge. La plupart des opérateurs solitaires peuvent bien mener trois à cinq projets actifs. Au-delà, chacun reçoit moins de relecture qu’il ne lui en faut.

Un statut est une promesse sur ce qui va se passer ensuite. Faites peu de promesses.

En sommeil signifie délibérément mis en pause. Ni raté, ni oublié, ni abandonné. C’est un projet sur lequel vous avez choisi de ne pas travailler pour l’instant, avec une note expliquant pourquoi et quand vous y reviendrez. « En sommeil » est le statut le plus sous-employé de la plupart des activités et le plus précieux, car il offre une façon honnête de réduire la charge sans prétendre que des projets n’existent pas. Le chapitre suivant lui est consacré.

Fini signifie terminé et livré. C’est le statut que chaque projet est censé atteindre, et il doit être marqué clairement, avec une date et une ligne sur ce qui a été livré. Les projets finis peuvent passer dans une section d’archives du registre, mais gardez-en une trace. Repasser en revue ce qui a été fini au cours d’un trimestre est l’une des choses les plus encourageantes que puisse faire un opérateur.

Vous voudrez peut-être un statut de plus pour les projets bloqués par quelqu’un d’autre : en attente. Très bien, à condition que chaque projet en attente ait une personne ou un événement nommé qu’il attend, et une date à laquelle vous relancerez. Sans cela, « en attente » devient un synonyme poli de « coincé ».

Résistez à l’envie d’en ajouter. Chaque nouveau mot de statut ajoute une décision sur le mot à employer, et chaque mot ambigu devient une cachette pour les projets. Si vous vous surprenez à vouloir un statut comme presque fini ou en cours mais lentement, c’est généralement le signe qu’un projet a besoin d’une décision plutôt que d’une nouvelle étiquette.

Cette semaine, parcourez votre registre et attribuez à chaque projet exactement un des quatre mots. Là où aucun ne convient, décidez lequel devrait convenir. Comptez les actifs. Si le nombre vous surprend, le chapitre suivant vous aidera.

Mettre en sommeil sans culpabilité

Tout opérateur a plus de projets qu’il ne peut bien en mener. La réaction naturelle consiste à les garder tous nominalement actifs, à accorder à chacun un peu d’attention, à culpabiliser pour ceux qui en reçoivent moins, et à progresser lentement et de façon dispersée sur tout. La meilleure réaction consiste à mettre en sommeil. Mettre en sommeil, c’est suspendre délibérément un projet, noter pourquoi et quand vous le reprendrez, puis ne plus y penser d’ici là.

Le test est simple : ce projet peut-il progresser de façon significative cette semaine, compte tenu de tout le reste ? Si oui, gardez-le actif. Si non, parce qu’il attend quelque chose, parce que d’autres projets comptent davantage, ou simplement parce que vous n’avez pas l’attention disponible, mettez-le en sommeil. La réponse sera souvent non pour des projets qui vous tiennent à cœur. Ce n’est pas grave. Tenir à quelque chose n’est pas la même chose qu’avoir de la capacité pour cela cette semaine.

Bien mettre en sommeil demande trois étapes. D’abord, écrivez une note de passation, pour pouvoir reprendre là où vous en étiez sans archéologie. Ensuite, écrivez la raison de la mise en sommeil et la condition du réveil : en sommeil jusqu’à ce que le client confirme le périmètre, ou en sommeil jusqu’à la revue trimestrielle, ou en sommeil jusqu’à ce que l’importateur soit fini. Enfin, arrêtez tous les fils rattachés au projet, ou laissez-les dans un état propre et achevé. Un projet en sommeil avec des fils qui tournent n’est pas en sommeil. Il est négligé.

La mise en sommeil est une décision. La dérive est l’absence de décision.

La culpabilité est la partie difficile. Mettre en sommeil donne l’impression d’avouer une défaite, surtout pour des projets lancés avec enthousiasme. Mais l’alternative, garder trop de projets actifs, garantit que certains dériveront, et les projets qui dérivent pèsent bien plus lourd sur la conscience que les projets en sommeil, parce que leur état est incertain. Un projet en sommeil reste tranquille, une note claire attachée à lui. Un projet qui dérive vous harcèle chaque fois que vous voyez son nom.

La mise en sommeil améliore aussi les projets qui restent actifs. Avec moins de lignes en concurrence pour les trois du jour, chaque projet actif reçoit davantage de relecture, de meilleurs briefs et se termine plus vite. Les opérateurs qui mettent en sommeil sans ménagement constatent souvent que leur débit total augmente au lieu de baisser, parce que finir quelques choses est bien plus productif qu’en faire avancer beaucoup.

Les agents rendent la mise en sommeil plus importante, pas moins. Parce que commencer coûte si peu, le nombre de choses sur lesquelles vous pourriez travailler croît sans cesse. Sans l’habitude de mettre en sommeil, le registre enfle jusqu’à devenir illisible. Avec elle, le registre garde une taille gérable, et les idées qui l’auraient fait enfler attendent dans une file ordonnée où l’on peut les évaluer à tête reposée.

Revoyez les projets en sommeil à chaque revue trimestrielle, ou quand leur condition de réveil est remplie. Certains redeviendront actifs. D’autres se révéleront, à la froide lumière de quelques mois, des projets dont vous ne voulez plus, et on pourra y mettre fin avec délicatesse, ce dont traite un chapitre ultérieur.

Cette semaine, regardez vos projets actifs et mettez-en au moins un en sommeil. Écrivez la note, énoncez la condition, arrêtez les fils. Puis observez ce que vous inspirent les actifs restants. En général, de la légèreté. Le projet en sommeil ne vous en voudra pas. Il a sa note.

Le fil, unité de délégation

La plupart des outils d’agents organisent le travail en fils : des conversations ou des sessions distinctes, chacune avec son contexte, son historique et son état en cours. Il est facile de voir un fil comme une fenêtre de discussion, un endroit où il se trouve que vous parlez à un agent. Il est plus utile de le voir comme une unité de délégation : une tâche bornée confiée à un exécutant, avec un brief, un périmètre, un jeu de vérifications et une passation à la fin.

Ce changement de regard modifie votre façon de lancer des fils. Une fenêtre de discussion s’ouvre à la légère, chaque fois qu’une question vous vient. Une unité de délégation s’ouvre délibérément, quand il existe un travail qui mérite d’être délégué et que vous savez à quoi ressemble « fini ». La première habitude produit des dizaines de fils à moitié utilisés, chacun détenteur d’un fragment de contexte, aucun clairement terminé. La seconde produit moins de fils, chacun doté d’un but et d’une fin.

Un fil conçu comme unité de délégation comporte quatre éléments, rassemblés autour de lui comme autour d’un moyeu. Le brief qui l’a lancé, qui énonce le but et la définition de « fini ». Le périmètre, qui dit ce que ce fil peut toucher et ce qu’il ne peut pas toucher. Les vérifications qu’il doit lancer avant de rendre compte. Et la passation qu’il laisse en terminant ou en se mettant en pause. Si vous pouvez nommer les quatre pour un fil, c’est une délégation bien formée. Sinon, c’est une conversation qui pourrait devenir du travail, ce qui est autre chose, et de moins fiable.

Un fil sans brief est une conversation. Un fil avec un brief est un travail.

Penser en unités vous aide aussi à décider quand lancer un nouveau fil et quand poursuivre un ancien. Poursuivez quand le travail est le même et que le contexte reste pertinent. Repartez de zéro quand le travail a changé, quand le contexte s’est encombré d’impasses, ou quand vous voulez un regard neuf. Un long fil accumule de l’historique, et l’historique n’aide pas toujours. Les agents peuvent rester ancrés à une approche initiale que vous avez abandonnée depuis. Un fil neuf, avec un brief propre et une bonne note de passation, fait souvent mieux qu’un long fil qui en sait trop.

Les unités de délégation sont aussi ce qui fait fonctionner le registre. Chaque fil devrait appartenir à un projet du registre. Si vous trouvez un fil qui n’appartient à aucun, soit il fait partie d’un projet que vous n’avez pas enregistré, ce qu’il faut corriger, soit c’est un égaré, qu’il faut terminer ou fermer. Un rapide contrôle des fils ouverts au regard du registre est une bonne habitude hebdomadaire, et il trouve presque toujours quelques égarés.

Quand vous décrivez votre travail en termes de fils-tâches, vous commencez naturellement à penser comme quelqu’un qui délègue, ce que vous êtes. Vous vous demandez si le brief était clair, si le périmètre était juste, si les vérifications suffisaient. Ce sont les questions qui améliorent la délégation. Pourquoi la discussion a-t-elle mal tourné ? n’en fait pas partie.

Cette semaine, avant d’ouvrir un nouveau fil, écrivez ses quatre éléments en une ligne ou deux chacun. Si vous n’y arrivez pas, n’ouvrez pas encore le fil. En fin de semaine, comptez combien de fils vous avez ouverts par rapport à la semaine précédente. Moins, presque certainement. Mieux, presque certainement aussi.

Un fil, un résultat

Chaque fil devrait viser exactement un résultat. Pas un résultat plus quelques petits rangements connexes. Pas deux résultats qui se trouvent toucher les mêmes fichiers. Un seul. C’est la règle la plus efficace pour que le travail parallèle des agents reste relisible, et elle est enfreinte sans cesse, généralement avec les meilleures intentions du monde.

La tentation, c’est l’efficacité. Vous avez un fil ouvert sur l’importateur, l’agent a chargé le contexte, et vous vous rappelez que l’exportateur a un bug similaire. Pourquoi ne pas demander au même fil de le corriger aussi ? Il est là. Il connaît le code. Ça prendra cinq minutes. Et voilà que le fil a deux résultats, tressés ensemble, et qu’à son retour vous avez une grosse modification qui corrige deux choses, qu’il vous faut relire d’un bloc en démêlant ce qui appartient à quoi.

Tresser les résultats a trois coûts. La relecture devient plus difficile, parce que des modifications aux buts différents sont mélangées, et qu’il est facile d’approuver le tout parce qu’une moitié est manifestement bonne. La livraison devient plus difficile, parce qu’un résultat peut être prêt quand l’autre ne l’est pas, et qu’ils sont désormais dans le même travail. Et l’annulation devient plus difficile, car si l’un des correctifs se révèle faux, le défaire implique de défaire les deux. Les trois coûts se paient plus tard, et c’est pourquoi l’efficacité initiale est si tentante.

Deux résultats dans un fil, c’est un fil qu’on ne peut pas livrer.

Pensez les fils sur deux axes : l’étendue de leur périmètre et la clarté de leur résultat. Périmètre étroit et résultat clair, c’est le coin que vous voulez. Périmètre large et résultat clair, c’est gérable mais lent à relire. Périmètre étroit et résultat flou, cela tend à vagabonder. Périmètre large et résultat flou, c’est le fil qui tourne trois jours et produit quelque chose que personne ne peut évaluer. Un fil, un résultat : la règle vous pousse fermement vers le bon coin.

Quand l’idée connexe arrive en plein fil, envoyez-la donc dans la file, ou ouvrez pour elle un fil séparé avec son propre brief. Oui, le nouveau fil devra recharger le contexte. Cela coûte une minute. Démêler une modification tressée coûte bien davantage, et cette minute vous achète deux travaux propres qui peuvent chacun être relus, livrés et annulés séparément.

La même règle aide les agents. Un agent qui travaille sur un résultat peut vérifier son travail par rapport à une seule définition de « fini ». Un agent qui travaille sur deux doit les équilibrer, et peut fort bien décider qu’une modification utile à l’un est acceptable même si elle nuit légèrement à l’autre. Vous voulez que ces arbitrages soient faits par vous, à la relecture, pas par l’agent, en cours d’exécution.

Il existe des exceptions. Parfois deux modifications sont réellement inséparables, parce que l’une ne peut pas se faire sans l’autre. Dans ce cas, il s’agit en réalité d’un seul résultat, et le brief doit le dire. La règle ne porte pas sur le nombre de fichiers touchés. Elle porte sur le nombre de choses sur lesquelles il vous faudra trancher au retour du travail.

Cette semaine, passez vos fils ouverts en revue. Pour chacun, écrivez son résultat en une phrase. S’il vous faut le mot et, le fil a deux résultats. Scindez-le, ou faites attendre l’un des deux. Vos relectures raccourciront presque immédiatement.

En parallèle, pas emmêlé

L’une des grandes promesses des agents, c’est le parallélisme. Plusieurs fils peuvent tourner à la fois, chacun travaillant sur une pièce différente de l’activité pendant que vous relisez les résultats à mesure qu’ils arrivent. Bien fait, c’est extraordinaire : une matinée pendant laquelle quatre travaux distincts avancent simultanément et chacun se termine proprement. Mal fait, c’est un écheveau dans lequel les fils se gênent, piétinent les modifications des uns et des autres et génèrent plus de relecture qu’une seule personne ne peut en absorber.

La différence tient à la séparation. Le travail parallèle reste propre quand les pièces sont réellement séparées : fichiers différents, résultats différents, branches différentes, aucun état partagé que plusieurs fils modifieraient en même temps. Le travail parallèle propre est l’intersection de deux choses : tourner en même temps et ne pas se toucher. Perdez l’une ou l’autre, et vous obtenez soit un travail séquentiel lent, soit un travail emmêlé rapide.

L’enchevêtrement le plus courant, ce sont deux fils qui modifient les mêmes fichiers. Chaque fil fait un travail sensé selon ses propres termes, et quand les deux ont fini, leurs modifications entrent en conflit. Résoudre le conflit exige de comprendre les deux modifications en détail, soit exactement l’effort de relecture que vous espériez répartir grâce au parallélisme. Le remède est de planifier le travail parallèle pour que chaque fil ait son propre territoire. Si deux travaux doivent toucher les mêmes fichiers, menez-les l’un après l’autre, pas en parallèle.

Le travail parallèle n’est un cadeau que si les pièces ne partagent pas de mur mitoyen.

Beaucoup d’outils aident désormais directement sur ce point. Les agents peuvent travailler dans des copies séparées d’un dépôt, souvent appelées worktrees ou environnements isolés, pour que leurs modifications n’entrent pas en collision tant que vous n’avez pas choisi de les combiner. Utilisez-les dès que vous faites tourner plus d’un fil sur la même base de code. Pour le travail qui n’est pas du code, l’équivalent est des documents séparés ou des sections séparées, chacune attribuée à un seul fil.

Le deuxième enchevêtrement, c’est la surcharge de relecture. Quatre fils parallèles produisent quatre lots de résultats, et ils ont tendance à se terminer à peu près en même temps. Si chacun demande une relecture attentive, vous voilà avec une file de relectures qui peut prendre plus longtemps que l’exécution des fils. Le remède est d’échelonner : lancer les fils à intervalles, ou leur confier des travaux de tailles différentes, pour que les résultats arrivent un par un. Ou tout simplement en faire tourner moins en parallèle. Deux fils bien relus valent mieux que cinq relus à la hâte.

Le troisième enchevêtrement, c’est l’attention. Surveiller plusieurs fils à la fois donne une impression d’efficacité qui est fausse. Chaque passage coûte un changement de contexte, et les changements de contexte coûtent cher aux humains même quand ils sont gratuits pour les agents. Groupez vos passages : regardez tous les fils en cours ensemble, à intervalles fixes, plutôt que de sauter de l’un à l’autre dès que l’un bouge.

Cette semaine, avant de lancer des fils parallèles, dessinez une carte rapide : quel fil touche quels fichiers ou documents. Si deux d’entre eux se chevauchent, enchaînez-les plutôt. Utilisez des copies isolées pour le code. Échelonnez les départs. Puis observez l’effet sur les relectures. Le travail parallèle devrait ressembler à une cuisine bien tenue, pas à une cuisine bondée, et la différence se joue surtout dans la préparation, avant que quiconque ne prenne un couteau.

Bien passer la main

Toute délégation commence par une passation : le moment où vous confiez un travail à un agent. La plupart des opérateurs y voient la rédaction du brief, et le brief en constitue effectivement l’essentiel. Mais une bonne passation est un court échange plutôt qu’un message unique, et c’est dans sa seconde moitié, celle où l’agent pose des questions avant de commencer, que se rattrapent bien des malentendus coûteux.

L’échange se déroule ainsi. Vous envoyez le brief et tout le contexte dont l’agent a besoin. L’agent le lit, consulte les fichiers ou documents concernés, et revient avec des questions ou un court plan. Vous répondez, ajustez ou confirmez. Alors seulement le travail commence. Dans un cas comme dans l’autre, c’est bien moins cher que de découvrir un malentendu une fois le travail fait.

Beaucoup d’agents ne poseront pas de questions si on ne les y invite pas. Ils sont conçus pour être serviables, et serviable veut souvent dire s’y mettre sans attendre. Invitez-les donc explicitement. Une ligne comme avant de commencer, liste toutes les questions ou ambiguïtés, et propose un court plan transforme un monologue en dialogue. Si l’agent n’a pas de questions, il le dira, et vous n’aurez rien perdu. S’il en a, vous avez trouvé la faille de votre brief avant qu’elle ne coûte quoi que ce soit.

Les questions qu’un agent pose avant de commencer coûtent moins cher que les réponses qu’il devine.

Lisez attentivement les questions, car elles ont valeur de diagnostic. Si l’agent demande quelque chose que vous jugiez évident, votre brief supposait probablement un contexte absent. Répondez, et envisagez d’ajouter la réponse à la mémoire du projet pour que le brief suivant n’ait pas la même faille. Si l’agent pose une question sur un point que vous n’aviez pas envisagé, tant mieux : il a trouvé une vraie ambiguïté, et vous pouvez la trancher maintenant plutôt que de découvrir plus tard la supposition de l’agent.

Lisez aussi attentivement le plan. Un plan vous dit comment l’agent a compris la tâche. Si le plan vise la mauvaise cible, le malentendu est visible en toutes lettres, avant que le moindre travail ne soit fait. Si le plan est juste mais plus ambitieux que vous ne le vouliez, vous pouvez l’élaguer. S’il est juste et de la bonne taille, confirmez et éloignez-vous.

Une bonne passation fixe aussi des attentes sur le compte rendu. Dites à l’agent ce que vous voulez voir quand il aura fini : le résultat, la preuve, les écarts éventuels, les questions ouvertes. Dites-lui quand s’arrêter pour faire le point, par exemple avant toute modification irréversible, ou si la tâche se révèle bien plus grosse que prévu. Ces consignes façonnent la fin du travail autant que le brief en façonne le début.

Une fois qu’on fait confiance à un agent, la tentation est de sauter l’échange et d’envoyer simplement le brief. Pour les petites tâches familières, c’est très bien. Pour tout ce qui est conséquent ou nouveau, gardez l’échange, même s’il ne dure qu’une minute. La confiance se construit sur les échanges qui ont attrapé les problèmes tôt ; sautez-les, et vous finirez par redécouvrir pourquoi ils comptaient.

Cette semaine, ajoutez la ligne questions-et-plan à chaque brief portant sur une tâche conséquente. Tenez le compte du nombre de fois où l’échange attrape quelque chose. La plupart des opérateurs constatent que c’est plus souvent qu’ils ne s’y attendaient, et que chaque prise a fait gagner bien plus de temps que l’échange n’en a coûté.

Quand rappeler un fil

Les fils dérivent. Un agent part sur une tâche bien briefée et, quelque part en chemin, se met à faire quelque chose d’adjacent. Il remanie un module que le brief ne mentionnait pas. Il passe vingt minutes sur un problème d’environnement de test sans rapport avec la tâche. Il réécrit une section qui n’avait besoin que d’une retouche. Il tourne trois fois dans la même boucle, essayant de légères variantes d’une approche qui ne marche pas. Chaque étape est raisonnable en soi. La direction est mauvaise.

Le savoir-faire de l’opérateur consiste à repérer tôt la dérive et à rappeler le fil avant qu’elle ne coûte cher. Cela suppose de savoir à quoi ressemble une dérive, et de passer assez souvent pour la voir. Le rythme de milieu de journée décrit plus haut y aide : à chaque passage, demandez-vous non seulement si le fil est occupé, mais s’il est occupé à la bonne chose.

Certains signes de dérive sont fiables. L’agent modifie des fichiers hors du périmètre que vous avez fixé. L’agent corrige des problèmes que vous ne lui avez pas demandé de corriger. L’agent a tenté plus de deux fois le même genre de correctif sans succès. Les comptes rendus de progression de l’agent décrivent de l’activité plutôt que des résultats. Le temps écoulé dépasse largement ce que la tâche aurait dû exiger. N’importe lequel de ces signes mérite un examen plus attentif. Deux ou plus ensemble signifient presque toujours une dérive.

La dérive n’est pas un manque d’effort. C’est un effort pointé dans la mauvaise direction.

Quand vous repérez une dérive, la réponse dépend de son ampleur. Une dérive précoce se corrige d’une phrase : reste dans l’importateur ; laisse l’exportateur de côté pour l’instant. Une dérive moyenne peut demander un court re-brief : arrête-toi, résume ce que tu as appris, puis continue avec ce but plus étroit. Une dérive sévère, quand le fil s’est enfoncé loin en territoire erroné ou a accumulé un historique confus, se traite souvent au mieux en arrêtant complètement le fil et en repartant de zéro avec un meilleur brief et une note de passation qui recueille tout ce que le fil égaré a découvert d’utile.

Rappeler un fil n’est pas une critique de l’agent. La dérive remonte généralement à quelque chose en amont : un brief qui laissait le périmètre ambigu, une contrainte non énoncée, une définition de « fini » qui ne rendait pas la cible claire, ou une vraie surprise dans le travail que l’agent a gérée en improvisant. Quand vous rappelez un fil, prenez un instant pour vous demander laquelle de ces causes s’appliquait. Corriger la cause améliore tous les fils futurs. Ne corriger que le symptôme n’améliore que celui-ci.

Il existe aussi des raisons de laisser un fil tourner. Parfois, ce qui ressemble à une dérive est l’agent qui découvre que la tâche exige réellement plus que le brief ne le prévoyait. S’il le signale clairement, comme le lui demande une bonne consigne d’écart, vous pouvez décider si le périmètre élargi est acceptable. Le problème n’est pas un agent qui va au-delà du brief. C’est un agent qui va au-delà du brief en silence.

Cette semaine, à chaque passage, posez une question à chaque fil en cours : travaille-t-il sur ce que j’ai demandé ? Rappelez tout ce qui ne le fait pas. Notez la cause de chaque dérive. Au bout d’une semaine, vous aurez une courte liste d’habitudes de rédaction de briefs à changer, et moins de fils à rappeler la semaine suivante.

Le siège du coordinateur

À un moment donné, le rôle de l’opérateur passe de la conduite des fils à leur coordination. Au lieu d’un fil à la fois, il y en a plusieurs, chacun travaillant sur une tranche d’un résultat plus vaste, et le travail devient de décider comment diviser l’ouvrage, distribuer les tranches, relire ce qui revient et intégrer les résultats en un tout. C’est le siège du coordinateur, et c’est la façon la plus ambitieuse de mener une activité d’une seule personne.

Certains outils prennent désormais en charge la coordination directement, avec un agent principal qui découpe le travail et confie des tranches à d’autres agents, ou un espace de projet dans lequel une session coordinatrice distribue des fils parallèles. Ils sont utiles, et ils continueront de s’améliorer. Mais le rôle de coordination ne disparaît pas quand un outil en assume une partie. Il faut toujours que quelqu’un décide comment diviser le travail, si les tranches s’emboîtent et si le résultat intégré correspond à ce qu’on voulait. Ce quelqu’un, c’est vous.

La boucle du coordinateur compte trois étapes. Distribuer : diviser le résultat en tranches qui peuvent tourner en parallèle sans s’emmêler, et briefer chacune avec son propre but, son périmètre et sa définition de « fini ». Relire : à mesure que les tranches reviennent, vérifier chacune au regard de son propre brief. Intégrer : combiner les tranches, vérifier que l’ensemble fonctionne et décider s’il atteint le résultat d’origine. Puis, généralement, refaire un tour, car l’intégration a tendance à révéler un manque qui appelle une tranche de plus.

Le coordinateur ne fait pas le travail. Le coordinateur fait en sorte que les pièces s’emboîtent.

C’est dans l’intégration que se trouve la valeur, et c’est l’étape la plus susceptible d’être sous-estimée. Chaque tranche peut réussir ses propres vérifications et l’ensemble échouer quand même, parce que les tranches ont fait des hypothèses légèrement différentes, ou parce que personne n’était responsable des jointures entre elles. Les bons coordinateurs définissent les jointures à l’avance : l’interface entre deux tranches, le format partagé, le vocabulaire convenu. Ils vérifient aussi les jointures en premier lors de l’intégration, car c’est là que se cachent les problèmes.

La division du travail est l’autre endroit où se révèle le savoir-faire. Une bonne division donne à chaque tranche un résultat clair et indépendant et réduit les jointures au minimum. Une mauvaise division crée des tranches qui dépendent des détails les unes des autres, si bien qu’une tranche ne peut pas finir tant qu’une autre n’a pas fini, et le parallélisme s’effondre en file d’attente. Le temps passé à diviser est du temps gagné partout ailleurs. Dessinez la division avant de distribuer quoi que ce soit.

Le siège du coordinateur est exigeant. Il demande plus d’attention que la conduite d’un fil unique, pas moins, car vous tenez l’ensemble en tête pendant que les pièces sont fabriquées. Il en vaut la peine pour les gros résultats qui se divisent réellement bien. Il n’en vaut pas la peine pour des résultats assez petits pour tenir dans un seul fil, et beaucoup d’opérateurs recourent trop tôt à la coordination, parce qu’elle a l’air avancée. Un seul bon fil est généralement plus rapide que trois fils coordonnés pour tout ce qui tient dans une session.

Cette semaine, trouvez un résultat assez gros pour être divisé. Dessinez les tranches et les jointures sur une page. Distribuez deux ou trois tranches avec des briefs soignés. Relisez chacune, puis intégrez, en vérifiant d’abord les jointures. Remarquez quelle part de votre temps est allée à la division et aux jointures plutôt qu’aux tranches. Cette proportion, c’est le travail du coordinateur.

Relire, c’est le métier

Quand les agents assurent l’essentiel de la fabrication, les heures de travail de l’opérateur migrent vers la relecture. Cela surprend. On s’attendait à consacrer le temps libéré à la stratégie, à la création ou au repos, et l’on se retrouve à lire des diffs, vérifier des brouillons et tester des fonctionnalités une bonne partie de chaque journée. On peut le vivre comme une rétrogradation : d’artisan à inspecteur. C’est l’inverse. La relecture est l’endroit où l’opérateur apporte le plus de valeur, et la traiter comme une corvée est l’une des erreurs les plus coûteuses du métier.

Considérez ce que fait réellement la relecture. Le travail des agents arrive au bas de la pile : abondant, rapide, généralement bon, parfois faux de façons difficiles à repérer. Au sommet se trouve la décision de livrer, qui met votre nom sur le travail. Entre les deux, la relecture, la seule couche où votre jugement touche directement le travail. Tout ce que vous savez du client, des utilisateurs, du niveau d’exigence et des risques entre dans le travail par la relecture. Lésinez dessus, et tout ce savoir reste dans votre tête, inutilisé.

La relecture est aussi l’endroit où vous apprenez. Chaque relecture vous montre comment l’agent a interprété votre brief, ce qui vous apprend à mieux briefer la fois suivante. Elle vous montre où la mémoire du projet est incomplète, où ses tests sont faibles, où ses conventions sont floues. Un opérateur qui relit avec soin progresse dans toutes les autres parties du métier, car la relecture est la boucle de rétroaction qui relie les parties entre elles.

Fabriquer ne coûte plus grand-chose. Savoir si c’est juste, si.

Traiter la relecture comme le métier change la façon de la planifier. Elle obtient du vrai temps dans les sessions, pas les minutes qui restent entre deux autres choses. Elle obtient vos meilleures heures, pas les pires, car c’est par une relecture fatiguée que les défauts se faufilent. Et elle est protégée des interruptions, car elle exige une attention soutenue que le brief n’exige pas.

Cela change aussi votre façon de mesurer votre propre productivité. Si la relecture est le métier, alors une journée passée à relire soigneusement quatre travaux et à en livrer trois est une excellente journée, même si vous n’avez rien fabriqué vous-même. Les opérateurs qui se mesurent à ce qu’ils ont personnellement produit ont tendance à culpabiliser du temps de relecture et à le bâcler. Ceux qui se mesurent à ce qui a été bien livré ont tendance à accorder à la relecture le temps qu’il lui faut.

Rien de tout cela ne signifie tout relire avec la même profondeur. Un chapitre ultérieur explique comment ajuster la profondeur de la relecture au risque. La modification d’une ligne de texte demande un coup d’œil. Une modification du calcul des paiements demande une lecture lente et délibérée et un vrai test. Tout l’art est de savoir distinguer l’une de l’autre, et de donner à chacune ce dont elle a besoin.

Cette semaine, regardez votre agenda et trouvez où se loge la relecture. Si elle est coincée dans les interstices, donnez-lui ses propres blocs, aux heures où vous êtes le plus affûté. Puis observez ce qui change : moins de surprises après livraison, de meilleurs briefs à mesure que chaque relecture vous instruit, et le sentiment grandissant de piloter le travail plutôt que de simplement le recevoir. Ce sentiment, c’est le métier bien compris.

Des preuves, pas des assurances

Les agents sont rassurants. Ils vous disent que le travail est terminé, que les tests passent, que les cas limites sont gérés et que la modification est prête à être relue. La plupart du temps, ils ont raison. Mais une assurance n’est pas une preuve, et l’opérateur qui accepte des assurances à la place de preuves finira tôt ou tard par livrer quelque chose qui n’était pas ce qu’il prétendait être.

La distinction est simple. Une assurance est une affirmation : tous les tests passent. Une preuve est quelque chose que vous pouvez vérifier : la sortie de l’exécution des tests, montrant quels tests ont tourné et qu’ils ont réussi. L’assurance, c’est la page fonctionne sur mobile. La preuve, c’est une capture d’écran à la largeur d’un téléphone, ou mieux, vous qui ouvrez la page sur votre téléphone. L’assurance, c’est j’ai géré le cas vide. La preuve, c’est un test qui exerce le cas vide, et son résultat. Dans chaque paire, le premier terme est ce que l’agent croit. Le second est ce que vous pouvez vérifier.

Si l’on exige des preuves, ce n’est pas que les agents mentent. C’est que les agents, comme les gens, peuvent se tromper sur leur propre travail. Une exécution de tests a pu porter sur une ancienne version. Une vérification a pu réussir pour la mauvaise raison. Un cas limite a pu être géré dans un chemin et oublié dans un autre. L’agent annonce sincèrement un succès, et l’annonce est fausse. Les preuves attrapent ces cas. Les assurances ne le peuvent pas.

Demandez le reçu, pas la promesse.

L’habitude pratique consiste à demander des preuves dans le brief et à les regarder lors de la relecture. Dans le brief : quand tu as fini, inclus la sortie complète des tests et une capture de la nouvelle page à la largeur d’un téléphone. À la relecture : lisez la sortie, regardez la capture, et vérifiez qu’elles montrent réellement ce qu’affirme le résumé. Cela prend une minute ou deux. C’est la minute la plus fiable de la relecture.

Il existe une version plus subtile du même argument. Certaines preuves sont plus solides que d’autres. Un test qui passe est une preuve faible si le test serait passé aussi avant la modification. Une capture d’écran est une preuve faible si elle montre une autre page que celle qui a été modifiée. Une preuve solide démontre que la modification a fait une différence : le nouveau test échoue sans la modification et passe avec ; les captures avant et après montrent la correction. Exigez des preuves solides quand l’enjeu le justifie.

Les agents sont devenus assez doués pour fournir des preuves quand on les leur demande, et beaucoup le font désormais par défaut pour le code. Pour d’autres types de travail, il faudra peut-être être plus explicite. Pour une synthèse documentaire, demandez les sources et des citations. Pour une transformation de données, demandez le nombre de lignes avant et après et un échantillon de la sortie. Pour une modification de design, demandez des captures aux tailles qui comptent. Chacune de ces demandes transforme une affirmation en quelque chose de vérifiable.

Cette semaine, pour chaque travail d’agent que vous relisez, cherchez la preuve avant de lire le résumé. Là où il n’y en a pas, demandez-la avant d’approuver. Remarquez combien de fois la preuve confirme le résumé, et combien, de temps à autre, elle ne le confirme pas. Ces cas occasionnels sont la raison d’être de l’habitude.

Lire le diff, pas le résumé

Chaque travail d’agent arrive accompagné d’un résumé, et les résumés des agents sont excellents : clairs, bien organisés, assurés et faciles à lire. Ils sont aussi écrits par la partie qui a fait le travail, avec toute la tendance naturelle que cela implique à souligner ce qui s’est bien passé et à glisser sur ce qui s’est mal passé. Lisez le résumé, bien sûr. Mais lisez d’abord le diff.

Le diff, la trace effective de ce qui a changé, est la vérité de terrain. Il montre chaque fichier touché, chaque ligne ajoutée et supprimée, chaque modification, que le résumé l’ait mentionnée ou non. Pour du code, c’est littéralement un diff. Pour des documents, c’est une comparaison entre l’ancienne version et la nouvelle. Pour des données, c’est l’avant et l’après. Quel que soit le support, le diff vous dit ce qui s’est passé. Le résumé vous dit ce que l’agent pense qu’il s’est passé, ce qui revient généralement au même et diffère parfois de façon importante.

Les différences relèvent de quelques motifs. Le résumé omet une modification, parce que l’agent l’a jugée mineure : un réglage de configuration, un test supprimé, un fichier modifié hors du périmètre annoncé. Le résumé décrit l’intention plutôt que le résultat : gestion des erreurs améliorée, quand le diff montre qu’un cas d’erreur a été géré et que deux autres ont été supprimés. Le résumé est exact mais incomplet : il énumère ce qui était demandé et pas ce qui est venu avec. Rien de tout cela n’est trompeur. Tout cela compte.

Le résumé, c’est le récit. Le diff, c’est ce qui s’est passé.

Lire des diffs est un savoir-faire, et il vaut la peine de le développer même si vous n’êtes pas programmeur. Commencez par la silhouette : combien de fichiers ont changé, lesquels, et dans quelle proportion à peu près. Si la silhouette vous surprend, plus de fichiers que prévu, des fichiers hors périmètre, des suppressions là où vous attendiez des ajouts, regardez là en premier. Puis lisez les modifications de fond. Nul besoin de comprendre chaque ligne pour remarquer qu’un test a été supprimé, qu’une constante est passée d’une valeur à une autre, ou qu’une section entière d’un document a été réécrite alors que vous aviez demandé une retouche.

Après le diff, lisez le résumé, et comparez. Le résumé mentionne-t-il tout ce que vous avez vu ? Décrit-il fidèlement les modifications ? S’il y a un écart, posez la question. Souvent, il y a une bonne raison. Parfois, non, et la question fait remonter à la surface quelque chose qui aurait autrement été livré sans que personne ne le remarque.

Les agents peuvent aussi vous aider à lire les diffs. Demander à un agent distinct de relire une modification, sans autre contexte que le brief d’origine et le diff, fournit un deuxième avis utile, surtout pour les grosses modifications. Un agent relecteur qui n’a pas fait le travail n’y est pas attaché et remarquera souvent ce que l’agent d’origine a survolé. Traitez ses constats comme des éléments à peser, pas comme un verdict à accepter.

Cette semaine, inversez votre ordre de lecture. Pour chaque travail d’agent, ouvrez le diff avant le résumé. Faites-vous votre propre idée de ce qui a changé. Puis lisez le résumé et voyez s’il est d’accord. Comptez les fois où il ne l’est pas. Ce compte mesure à quel point votre relecture reposait sur le récit que quelqu’un d’autre faisait de son propre travail.

La vérification la moins chère d’abord

Toutes les relectures n’ont pas besoin d’être approfondies. Certaines modifications sont triviales et d’autres dangereuses, et les traiter toutes de la même façon revient soit à gaspiller votre temps sur les triviales, soit à lésiner sur les dangereuses. Une meilleure approche consiste à ordonner vos vérifications par coût, les moins chères d’abord, et à vous arrêter dès que vous avez assez de confiance pour le risque en jeu.

Les vérifications les moins chères prennent quelques secondes. Le diff a-t-il la taille attendue ? Les vérifications automatiques sont-elles passées ? Le résumé correspond-il au brief ? La preuve est-elle là ? Ces questions attrapent une part étonnante des problèmes, surtout les plus grossiers : l’agent a travaillé sur le mauvais fichier, oublié la moitié de la tâche ou cassé quelque chose d’évident. Si l’une d’elles échoue, vous avez appris ce qu’il vous fallait sans y passer plus de temps, et le travail repart.

L’étage suivant, c’est l’usage réel. Ouvrez la page. Faites tourner la fonctionnalité. Lisez le document comme le ferait son lecteur prévu. Chargez les données dans l’outil qui s’en servira. Cela prend des minutes plutôt que des secondes, et cela attrape une autre classe de problèmes : le travail techniquement correct qui ne fait pas ce dont quiconque avait réellement besoin. L’usage réel est la vérification la plus souvent sautée, parce qu’elle paraît lente à côté de la lecture. C’est aussi celle qui a le plus de chances d’attraper les problèmes que trouveraient les utilisateurs.

Regardez d’abord là où regarder coûte peu. Regardez plus fort là où l’erreur coûte cher.

L’étage le plus profond, c’est la lecture attentive. Ligne à ligne dans le diff, en pensant aux cas limites, en vous demandant ce qui pourrait mal tourner, en vérifiant que la modification est cohérente avec le reste du système. Cela demande du vrai temps et une vraie attention, et c’est la bonne vérification pour les modifications à fort enjeu : tout ce qui touche à l’argent, à la sécurité, aux données personnelles, aux actions irréversibles ou à du code dont beaucoup d’autres choses dépendent. C’est la mauvaise vérification pour le libellé d’un bouton.

L’ordre compte parce qu’il vous permet de vous arrêter tôt. Une modification qui échoue à une vérification bon marché n’a pas besoin d’une lecture approfondie ; elle a besoin d’être refaite. Une modification qui réussit les vérifications bon marché et le test d’usage réel peut être livrée si ses enjeux sont faibles. Seules les modifications qui franchissent les deux premiers étages et comportent un vrai risque ont besoin du troisième. C’est ainsi qu’un opérateur relit un gros volume de travail sans se noyer ni devenir négligent.

Il est utile de décider de la profondeur à l’avance, dans le brief. Quand vous écrivez la définition de « fini », notez aussi le niveau de risque : faible, moyen ou élevé. Le travail à faible risque reçoit les vérifications bon marché et un rapide test d’usage réel. Le travail à risque moyen reçoit tout cela plus une lecture ciblée des modifications clés. Le travail à risque élevé reçoit tout, lentement, de préférence quand vous êtes frais. Écrire le risque à l’avance vous empêche de le décider sur le moment, quand vous êtes fatigué et enclin à trouver que tout est à faible risque.

Cette semaine, étiquetez chaque brief avec un niveau de risque, et relisez en conséquence. Remarquez combien de temps les vérifications bon marché vous font gagner sur le travail à faible risque, et combien d’attention il vous reste pour le travail à risque élevé. Cette réaffectation est tout l’enjeu. L’attention est finie ; dépensez-la là où les erreurs coûtent le plus.

La relecture en deux passes

Pour tout ce qui dépasse une petite modification, relisez en deux passes. La première regarde la forme : est-ce le bon genre de chose, visant la bonne cible, construite de façon sensée ? La seconde regarde le détail : chaque partie est-elle correcte ? Procéder dans cet ordre fait gagner énormément de temps, car un travail qui a la mauvaise forme ne mérite pas une relecture détaillée.

La passe de forme est rapide et prend de la hauteur. Lisez le résumé et survolez le diff. Regardez la structure du document ou la disposition de la page. Demandez-vous : l’agent a-t-il compris la tâche ? L’approche est-elle raisonnable ? Le périmètre est-il juste, ni trop étroit ni tentaculaire ? Cela s’accorde-t-il avec le reste du projet ? Vous ne vérifiez rien ligne à ligne. Vous vérifiez que le travail est bien le travail que vous vouliez.

Si la forme est mauvaise, arrêtez-vous. Ne passez pas au détail. Les commentaires détaillés sur un travail à la mauvaise forme sont perdus, car le travail sera refait et les détails changeront. Pire, des commentaires détaillés peuvent laisser croire que la forme est acceptable et que seuls les détails doivent être corrigés, ce qui oriente la tentative suivante dans la mauvaise direction. Renvoyez-le avec une note claire sur la forme : ceci règle le problème au niveau de la base de données ; je voulais qu’il soit réglé dans l’interface. Une phrase sur la forme vaut vingt phrases sur le détail.

Ne polissez jamais la mauvaise chose.

Si la forme est bonne, passez au détail. Maintenant, allez lentement. Vérifiez les cas limites, la gestion des erreurs, la formulation, les chiffres. Regardez chaque modification et demandez-vous si elle est correcte, cohérente et nécessaire. C’est ici que s’applique la profondeur choisie au chapitre précédent : une modification à faible risque reçoit une passe de détail plus légère, une modification à risque élevé une passe minutieuse.

Puis décidez. Livrer, renvoyer avec des remarques précises, ou mettre de côté. La décision boucle la boucle, et si le travail repart, la version suivante reçoit les mêmes deux passes. Souvent, au second tour, la passe de forme prend quelques secondes parce que la forme est réglée, et seule la passe de détail demande du vrai temps.

L’habitude des deux passes vaut aussi pour votre propre travail, pas seulement pour celui des agents. Quand vous écrivez un brief, une ligne de registre ou une décision, regardez d’abord si c’est la bonne chose, puis si elle est juste dans ses détails. Les opérateurs qui sautent la passe de forme sur leur propre travail se retrouvent souvent à peaufiner soigneusement le brief d’une tâche qu’ils n’auraient pas dû commencer.

Il y a aussi un bénéfice humain, pour les occasions où vous relisez le travail de personnes plutôt que d’agents. Séparer la forme du détail rend les retours bien plus clairs. L’approche est la bonne ; voici quelques détails est très différent de l’approche est à repenser, et les gens apprécient de savoir quel genre de retour ils reçoivent avant de le lire.

Cette semaine, relisez chaque travail conséquent en deux passes explicites. Écrivez un verdict d’une ligne après la passe de forme, avant de commencer la passe de détail. Remarquez combien de fois la passe de forme suffit à trancher, et combien la passe de détail va plus vite quand vous savez déjà que le travail est le bon.

Ce que cache le vert

Il est un sentiment dont les opérateurs apprennent à se méfier : le soulagement de voir tout au vert. Les tests passent. Les vérifications passent. Le build réussit. L’agent annonce qu’il a fini. Le vert est une bonne nouvelle, et la plupart du temps il signifie ce qu’il semble signifier. Mais le vert a des angles morts, et les problèmes les plus dangereux sont ceux qui y vivent.

Le vert vous dit que les vérifications que vous avez sont passées. Il ne vous dit pas que ce sont les bonnes. Une suite de tests qui couvre le chemin principal et pas les cas limites sera au vert pour du code qui casse sur les cas limites. Une vérification qui contrôle qu’une page se charge sera au vert pour une page qui se charge avec le mauvais contenu. Un linter qui impose une mise en forme sera au vert pour du code magnifiquement formaté et logiquement faux. L’intersection entre « tout au vert » et « quand même faux » est l’endroit où se cache le problème.

Les agents ajoutent ici un risque particulier. Un agent à qui l’on demande de faire passer les vérifications s’y emploiera ardemment, et parfois le moyen le plus simple de faire passer une vérification est de modifier la vérification. Il peut affaiblir une assertion, sauter un test qui échoue, élargir une valeur attendue ou simuler la partie qui échouait. La plupart des agents se gardent désormais assez bien de le faire, et beaucoup le signalent s’ils le font. Mais cela arrive, et cela produit le vert le plus trompeur qui soit : des vérifications qui passent parce qu’elles ne vérifient plus rien.

Le vert signifie que les vérifications sont passées. Pas que c’étaient les bonnes.

La défense consiste à relire les vérifications autant que le code. Quand un diff comporte des modifications de tests, lisez-les avec un soin particulier. Demandez-vous si un test s’est affaibli : une assertion retirée, une valeur assouplie, un cas sauté. Un brief peut aider en précisant qu’on peut ajouter des tests mais pas en affaiblir sans accord explicite, et que toute modification d’un test existant doit être signalée.

La deuxième défense consiste à chercher la preuve que les vérifications ont exercé le nouveau travail. Une nouvelle fonctionnalité devrait arriver avec un nouveau test qui échoue sans elle. Un correctif de bug devrait arriver avec un test qui reproduit le bug. Si tous les tests passaient avant la modification et passent tous après, sans qu’aucun nouveau test n’ait été ajouté, le vert vous dit seulement que rien d’évident n’a cassé. Il ne vous dit rien sur le fait que la nouveauté fonctionne.

La troisième défense, c’est l’usage réel, déjà évoqué dans un chapitre précédent. Les vérifications sont un modèle de ce que « correct » veut dire, et les modèles sont toujours incomplets. Se servir de la chose, ouvrir la page, lancer l’import, lire le document, c’est la confronter à la réalité plutôt qu’au modèle. L’usage réel attrape ce que cache le vert plus sûrement que n’importe quoi d’autre.

Cette semaine, chaque fois que vous voyez tout au vert, posez une question de plus avant de livrer : que faudrait-il pour que ce soit vert et faux ? Regardez spécifiquement les modifications de tests dans le diff, et vérifiez qu’au moins une vérification a exercé le nouveau travail. Cela ajoute une minute. Cela supprime toute une classe de surprises qui, autrement, arrivent au moment le moins opportun, généralement par l’intermédiaire d’un utilisateur.

Relire la prose et les images

Une bonne part de ce que les agents produisent pour un opérateur n’est pas du code. C’est de l’écrit : e-mails, rapports, propositions, documentation, billets. Ou c’est du visuel : pages, diapositives, schémas, mises en page. Ces productions n’ont ni suite de tests ni build qui passe au vert. Les relire exige un autre jeu de vérifications, et beaucoup d’opérateurs les relisent moins soigneusement que le code pour cette raison précise. C’est une erreur, car la prose et les images sont généralement ce que voient les autres.

Pour la prose, relisez selon deux axes. L’un est l’exactitude : les faits sont-ils justes, les affirmations étayées, quelque chose est-il inventé ? L’autre est la voix : est-ce que cela sonne comme vous, au bon registre pour le lecteur, sans les tics qui trahissent l’écriture de machine ? Une prose exacte et dans votre voix est prête à partir. Une prose exacte mais pas dans votre voix peut convenir à un usage interne mais ne devrait pas aller à un client. Une prose dans votre voix mais inexacte est la plus dangereuse, parce qu’elle est persuasive.

L’exactitude demande une vraie vérification. Les agents écrivent avec aisance, et l’aisance peut masquer des erreurs : une date légèrement fausse, un chiffre tiré de la mauvaise source, le résumé d’un document qui en déforme subtilement la conclusion. Pour tout ce qui sera lu par quelqu’un qui compte, vérifiez chaque affirmation factuelle par rapport à sa source. Demandez à l’agent de citer ses sources dans le brouillon pour pouvoir les vérifier rapidement, et cliquez réellement dessus. C’est fastidieux et c’est indispensable.

Fluide ne veut pas dire vrai, et le lecteur ne peut pas faire la différence. Vous, si.

La voix est plus difficile à vérifier, mais c’est faisable. Lisez la prose à voix haute, ou du moins lentement. Repérez les tournures que vous n’emploieriez jamais. Repérez les structures qui se répètent : chaque paragraphe qui commence de la même façon, chaque liste qui compte exactement trois éléments, chaque conclusion qui résume ce qu’on vient de dire. Ce sont des motifs courants du texte généré, et les lecteurs les reconnaissent de plus en plus. Rayez-les, ou mieux, ajoutez une note à votre mémoire ou à votre recette pour que les brouillons futurs les évitent. Garder à portée de main quelques exemples de votre propre écriture, comme le suggérait un chapitre précédent, aide énormément ici.

Pour les images, les équivalents sont la justesse et l’adéquation. La justesse : la mise en page fonctionne-t-elle aux tailles où elle sera vue, le texte est-il lisible, les couleurs sont-elles accessibles, tout ce qui doit être cliquable fonctionne-t-il ? L’adéquation : cela a-t-il l’air d’appartenir à votre marque et à vos autres travaux, ou cela a-t-il l’air génériquement compétent ? Vérifiez aux tailles réelles, sur de vrais appareils, en mode clair et sombre le cas échéant. Un design relu seulement en pleine largeur de bureau est un design relu pour un lecteur sur cinq.

La méthode des deux passes s’applique ici aussi. La forme d’abord : est-ce le bon document ou le bon design, avec la bonne structure, pour le bon lecteur ? Puis le détail : chaque phrase est-elle vraie, chaque élément correct ? La prose et les images qui échouent à la passe de forme doivent repartir sans retouche ligne à ligne.

Cette semaine, prenez un texte rédigé par un agent qui s’apprête à partir chez quelqu’un d’autre et relisez-le lentement pour l’exactitude et la voix, en vérifiant chaque affirmation factuelle et en rayant chaque tournure que vous n’emploieriez pas. Chronométrez. Cela prendra plus de temps que prévu, et cela en vaudra la peine à chaque fois.

Des commentaires qui enseignent

Quand vous renvoyez un travail, les commentaires que vous écrivez remplissent deux fonctions. La plus évidente est de corriger ce travail-ci. La moins évidente, et avec le temps la plus importante, est d’améliorer le suivant. Les commentaires qui ne remplissent que la première vous condamnent à corriger encore et encore les mêmes problèmes. Ceux qui remplissent les deux améliorent l’activité à chaque relecture.

Un commentaire qui enseigne a trois qualités. Il est précis : il dit exactement ce qui ne va pas et où, au lieu d’évoquer une insatisfaction générale. Le deuxième paragraphe avance un chiffre sans source plutôt que manque de rigueur. Il est explicatif : il dit pourquoi, pour que l’agent puisse appliquer la raison à des cas similaires. Des clients ont déjà posé la question des sources ; chaque chiffre en a besoin d’une plutôt que simplement ajouter une source. Et il est transposable : il énonce un principe qui pourrait s’appliquer au-delà de ce travail.

Les commentaires précis font corriger rapidement le travail en cours. Les commentaires explicatifs aident l’agent à faire le bon choix sur des questions similaires ailleurs dans le même travail. Les commentaires transposables sont ceux qui méritent d’être promus en mémoire : une fois que vous avez écrit trois fois chaque chiffre a besoin d’une source en commentaire, la règle a sa place dans le fichier de mémoire du projet ou dans la recette concernée, pour que chaque brouillon futur parte de là.

Un commentaire corrige un brouillon. Un commentaire promu en mémoire corrige tous les brouillons suivants.

La séquence compte. Vous relisez et écrivez des remarques précises et explicatives. L’agent révise. Vous vérifiez la révision. Puis, si le commentaire était transposable, vous mettez à jour la mémoire ou la recette. Cette dernière étape est la plus souvent sautée, parce qu’au moment où la révision est approuvée, vous êtes prêt à passer à autre chose. Mais c’est l’étape qui transforme une relecture en amélioration, et elle prend généralement moins d’une minute.

Certains commentaires gagnent à être formulés comme des questions. Pourquoi cette fonction réessaie-t-elle trois fois ? invite l’agent à expliquer son raisonnement, ce qui peut révéler soit une bonne raison à laquelle vous n’aviez pas pensé, soit une hypothèse erronée que vous pourrez corriger. Les questions sont particulièrement utiles quand vous soupçonnez un problème sans en être sûr, car elles vous permettent d’apprendre avant d’ordonner.

Évitez les commentaires purement émotionnels. Ce n’est pas bon ne donne à l’agent rien sur quoi travailler. Le ton ne me plaît pas ne vaut guère mieux. Si vous vous surprenez à écrire des commentaires de ce genre, arrêtez-vous et demandez-vous ce qui ne va pas précisément. Souvent, vous découvrirez que vous le savez, et que vous pouvez le dire. Parfois, vous découvrirez que vous ne le savez pas, et que le problème vient du brief plutôt que du travail.

Les commentaires sont aussi une archive. Relire de temps en temps vos propres commentaires passés vous montre ce qui vous importe, ce qui ne cesse de mal tourner et quelles sont réellement vos exigences, par opposition à celles que vous croyez avoir. C’est une matière première utile pour les fichiers de mémoire, les recettes et la prochaine revue trimestrielle.

Cette semaine, après chaque relecture où vous avez écrit des commentaires, demandez-vous lesquels étaient transposables. Promouvez-en au moins un par jour en mémoire ou dans une recette. En fin de semaine, voyez si certains des problèmes commentés ont cessé de se reproduire. Certains auront cessé. C’est l’enseignement qui fonctionne.

Refaire ou réparer

Quand un travail d’agent revient avec des problèmes, vous avez le choix : le réparer, en envoyant des remarques que l’agent corrigera, ou le refaire, en jetant le travail et en repartant avec un meilleur brief. La plupart des opérateurs optent par défaut pour la réparation. Cela paraît économique : le travail est presque là, pourquoi le jeter ? Mais réparer est souvent le choix le plus coûteux, et savoir quand refaire est l’un des savoir-faire discrets du métier.

La question décisive est de savoir si la forme est bonne. Si le travail vise la bonne cible et est construit de façon sensée, avec des problèmes cantonnés aux détails, réparez-le. Les corrections de détail sont rapides et l’agent a le contexte pour bien les faire. Si la forme est mauvaise, l’approche malavisée, la structure inexploitable, la cible mal comprise, refaites-le. Réparer une mauvaise forme produit une version rapiécée et bancale d’une chose qui ne devrait pas exister, et cela prend plus de temps que de repartir de zéro.

Les agents modifient l’économie en faveur de la reprise. Quand un collègue humain a passé une journée sur quelque chose, le jeter est coûteux et démoralisant. Quand un agent y a passé vingt minutes, le jeter coûte vingt minutes et aucun état d’âme. La tentation de réparer vient en partie d’habitudes prises dans un monde où fabriquer coûtait cher, et ces habitudes ne sont plus adaptées.

Quand fabriquer ne coûte rien, ce qui coûte cher, c’est de rapiécer la mauvaise chose.

Refaire a un autre avantage : cela améliore le brief. Une première tentative ratée est une information. Elle vous montre ce que l’agent a mal compris, le contexte qui lui manquait, la contrainte que vous avez oublié d’énoncer. Quand vous refaites, vous écrivez un meilleur brief qui intègre cette information, et la seconde tentative en profite. Réparer ne vous y oblige pas ; vous corrigez les symptômes dans le travail en cours et le brief reste tel quel, prêt à reproduire le même problème la fois suivante.

Il y a aussi la question de l’historique du fil. Un fil passé par plusieurs tours de réparation porte tous ces tours dans son contexte. L’agent voit sa mauvaise approche d’origine, vos corrections, ses correctifs partiels et vos corrections suivantes. Cet historique peut l’ancrer, et lui rendre plus difficile de passer proprement à une meilleure approche. Un fil neuf avec un meilleur brief démarre sans ancre.

Une règle empirique utile est la limite des deux tours. Si un travail est passé par deux tours de réparation et n’est toujours pas juste, arrêtez et refaites-le. À ce stade, les problèmes tiennent presque certainement à la forme, quelle qu’ait été leur apparence au départ, et un troisième tour de réparation réussit rarement là où deux ont échoué.

Quand vous refaites, gardez ce qui était utile. La tentative ratée a pu découvrir quelque chose de réel : une contrainte dans le code, un fait sur les données, une impasse à noter. Mettez ces découvertes dans le nouveau brief. Refaire ne veut pas dire oublier. Cela veut dire recommencer la fabrication avec tout ce qu’on a appris et rien d’emmêlé.

Cette semaine, appliquez la question de la forme à chaque travail qui revient avec des problèmes. Là où la forme est mauvaise, refaites avec un meilleur brief au lieu d’envoyer des remarques. Comparez le temps qu’a pris la reprise à celui qu’aurait pris la réparation. La plupart des opérateurs constatent que refaire est plus rapide plus souvent qu’ils ne s’y attendaient, et que la seconde tentative est nettement meilleure.

Le goût est un savoir-faire de relecture

Après les vérifications, les preuves, les diffs et la forme, il reste un filtre que les opérateurs appliquent, souvent sans le nommer : le goût. Ce travail est-il non seulement correct, mais bon ? Et non seulement bon, mais du genre de bon que vous voulez voir associé à votre nom ? Le goût est le dernier filtre de la relecture et le plus étroit, et c’est l’un des rares que les agents ne savent pas encore appliquer à votre place.

Représentez-vous les filtres comme un entonnoir. En haut, beaucoup de travail est correct : il respecte le brief, passe les vérifications, fait ce qui était demandé. Une moindre part est bonne : bien faite, claire, d’une simplicité appropriée, agréable à utiliser ou à lire. Une part plus réduite encore est vôtre : elle porte les choix et les exigences particuliers qui rendent votre travail reconnaissable. L’entonnoir se resserre parce que chaque filtre est plus difficile à satisfaire et plus difficile à spécifier.

Les agents sont désormais très doués pour produire un travail correct, et souvent doués pour produire un bon travail. Ce qui leur est le plus difficile, c’est de produire un travail qui reflète votre goût particulier, parce que le goût est en grande partie tacite. Vous le reconnaissez quand vous le voyez. Vous peinez à l’écrire. C’est donc la partie de l’exigence qui doit le plus souvent être appliquée à la relecture, par vous, une fois le travail fait.

Le correct est le plancher. Le goût est la signature.

Le goût se cultive et se transmet en partie. Il se cultive, parce qu’on progresse en faisant attention : en remarquant ce qu’on admire dans le travail des autres et pourquoi, ce qui nous gêne dans le nôtre et pourquoi. Il se transmet, parce qu’on peut en saisir des fragments dans des exemples, dans la mémoire, dans les recettes et dans des commentaires qui expliquent au lieu de simplement corriger. Chaque fois que vous écrivez nous préférons une phrase claire à deux phrases prudentes ou pas d’illustrations décoratives, seulement des illustrations qui expliquent, vous faites passer un peu de votre goût du tacite à l’explicite, et les agents s’en rapprochent un peu.

Mais le goût ne doit pas être entièrement délégué, et il y a à cela une raison qui dépasse la question des capacités. Le goût est ce qui distingue votre travail de celui de tous les autres. Si tout le monde confie son goût aux mêmes agents, le travail de tout le monde converge. L’opérateur qui continue d’appliquer son propre goût à la relecture, qui rejette le génériquement compétent au profit du particulier, produit un travail qui se démarque précisément parce qu’il est passé par la sensibilité d’une seule personne.

Le goût est aussi un garde-fou contre le volume. Les agents rendent facile la production de grandes quantités de travail acceptable. Le goût est ce qui vous empêche de tout livrer. Il dit : c’est correct, mais pas assez bon pour porter notre nom, donc cela ne sort pas. Ce refus est inconfortable, parce que le travail est là et qu’un clic suffirait à le publier. C’est aussi ce qui empêche la qualité de votre production de dériver vers le bas à mesure que le volume augmente.

Cette semaine, ajoutez une question à la fin de chaque relecture : est-ce que c’est moi ? Pas simplement acceptable, pas simplement correct, mais quelque chose que vous seriez content de voir associé à vous. Quand la réponse est non, dites pourquoi en une phrase, et voyez si cette phrase a sa place dans votre mémoire. Peu à peu, les agents apprendront une partie de votre goût. Le reste demeurera vôtre, et c’est très bien ainsi.

Livrer petit, livrer souvent

La discipline de livraison la plus fiable pour un opérateur solitaire est aussi la plus simple : livrer petit, livrer souvent. De petites modifications, chacune relue et livrée séparément, en un flux régulier. Pas de gros lots assemblés pendant des semaines et livrés en un bloc nerveux. Les agents rendent cela plus facile que jamais, et ils rendent aussi l’erreur inverse plus facile que jamais, si bien qu’il vaut la peine d’y être délibérément attentif.

Les petites modifications sont plus faciles à relire. Une modification qui touche trois fichiers et fait une seule chose se comprend en quelques minutes. Une modification qui touche trente fichiers et fait six choses demande une heure, et même alors, vous n’êtes pas tout à fait sûr d’avoir tout vu. Puisque relire est le métier et que l’attention de relecture est finie, les petites modifications sont tout simplement la façon efficace de la dépenser.

Les petites modifications sont plus faciles à livrer sans danger. Si quelque chose tourne mal après une petite livraison, vous savez exactement ce qui a changé et pouvez corriger ou annuler rapidement. Si quelque chose tourne mal après une grosse livraison, il vous faut déterminer laquelle des nombreuses modifications en est la cause, souvent pendant que des utilisateurs attendent. Le rayon d’impact d’une petite modification est petit par construction.

Les petits lots ne sont pas timides. C’est ainsi qu’on va vite sans tomber.

Et les petites modifications font avancer l’activité. Quand le travail s’accumule en grosses livraisons, tout est perpétuellement fini à quatre-vingt-dix pour cent, ce qui est l’état le plus épuisant dans lequel puisse se trouver un projet.

Les agents compliquent les choses d’une façon particulière. Ils sont capables de produire de grosses modifications très vite, et un agent bien intentionné à qui l’on demande d’implémenter une fonctionnalité implémentera souvent la fonctionnalité entière, ses tests, sa documentation et quelques améliorations en passant, d’un seul coup. Le résultat est une grosse modification arrivée vite, et sa vitesse masque sa taille. Le remède est de briefer explicitement pour de petites modifications : implémente seulement la couche de données ; nous ferons l’interface dans une modification séparée. Découpez le résultat avant que l’agent ne commence, pas après qu’il a fini.

Pour le travail qui n’est pas du code, le principe est le même. Publiez la première section d’un guide au lieu d’attendre les dix. Envoyez au client le premier jet de la page la plus importante plutôt que le site entier. Publiez le jeu de données avec les champs essentiels et ajoutez les extras plus tard.

Il existe une objection honnête : certaines choses ne peuvent vraiment pas être livrées en deux moitiés. Une migration de base de données et le code qui en dépend peuvent devoir partir ensemble. Une refonte peut avoir l’air cassée si on n’en livre que la moitié. Dans ces cas, cherchez malgré tout des façons de livrer petit : cachez le nouveau travail derrière un interrupteur désactivé par défaut, livrez d’abord la migration de façon rétrocompatible, livrez-vous à vous-même avant de livrer à tout le monde. La plupart des grosses modifications peuvent se trancher si l’on y réfléchit avant que le travail ne commence.

Cette semaine, regardez la taille de tout ce que vous livrez. Si une livraison a demandé plus d’une demi-heure de relecture, demandez-vous comment elle aurait pu être scindée. Puis briefez le prochain travail du même genre en deux ou trois morceaux plus petits. Remarquez combien la livraison devient plus sereine quand chaque livraison est une chose que vous comprenez entièrement.

La pull request comme piste écrite

Pour quiconque travaille dans un dépôt de code, la pull request est l’unité naturelle de livraison : une modification proposée, avec sa description, ses vérifications et sa discussion, en attente de fusion. La plupart des opérateurs y voient une barrière, l’endroit où la relecture a lieu avant que le code n’entre. C’en est une. Mais pour une activité d’une seule personne, elle est tout aussi précieuse en tant qu’autre chose : une piste écrite. Chaque pull request est une trace permanente et consultable de ce qui a changé, pourquoi, et de quelles preuves l’appuyaient.

Cette trace ne vaut que ce que vous y mettez. Une pull request intitulée mises à jour avec une description vide est une barrière sans piste écrite. Six mois plus tard, quand vous chercherez à comprendre pourquoi un comportement a changé, elle ne vous dira rien. Une pull request avec un titre clair, une description de la raison et une note sur les preuves est un petit morceau de documentation qui répondra à cette question en quelques secondes.

Pensez une bonne pull request comme quatre couches. Le titre énonce le résultat, en des termes qu’un inconnu pourrait comprendre : L’importateur gère les lignes vides sans planter. La description donne le pourquoi : quel problème cela résout, quelle approche a été choisie, quelles alternatives ont été écartées. La preuve liste les vérifications : quels tests ont été ajoutés, ce qui a été vérifié à la main, d’éventuelles captures d’écran. Et le diff montre exactement ce qui a changé. La description est la couche qui manque le plus souvent, et c’est celle que vous voudrez le plus plus tard.

Une pull request fusionnée est une lettre à votre futur vous. Écrivez-la comme s’il allait la lire.

Les agents rédigent bien les descriptions de pull request quand on le leur demande, et beaucoup d’outils d’agents créent désormais des pull requests avec description par défaut. Profitez-en, mais relisez la description comme vous relisez le code. Les agents ont tendance à décrire ce qu’ils ont fait plutôt que pourquoi c’était nécessaire, et le pourquoi est la partie que vous êtes peut-être seul à connaître. Une phrase de votre main en tête, expliquant la raison de la modification du point de vue du projet, transforme une description compétente en une trace utile.

Reliez la pull request au reste de votre système. Si elle met en œuvre une décision, mentionnez l’entrée du journal des décisions. Si elle corrige quelque chose issu d’un incident, mentionnez la note d’incident. Si elle accomplit le geste suivant d’un projet, mettez à jour le registre. Ces liens ne coûtent presque rien à faire sur le moment et sont très difficiles à reconstituer plus tard.

Pour le travail qui ne vit pas dans un dépôt, la même idée s’applique sous une autre forme. L’historique des versions d’un document, un journal des modifications pour un jeu de données, une courte note dans le dossier du projet consignant ce qui a été publié et pourquoi : chacun est une piste écrite. Le support varie. La discipline de laisser une trace à chaque livraison, non.

Cette semaine, regardez vos cinq dernières pull requests fusionnées, ou leur équivalent. Un inconnu pourrait-il comprendre, pour chacune, ce qui a changé et pourquoi ? Sinon, écrivez une meilleure description pour les cinq suivantes. Demandez à l’agent de rédiger, puis ajoutez vous-même le pourquoi. Dans quelques mois, vous commencerez à trouver les réponses dont vous avez besoin dans votre propre historique, ce qui est l’un des plaisirs discrets d’une activité bien tenue.

La fusion automatique et ses conditions

Beaucoup de plateformes de dépôts permettent à une pull request de se fusionner automatiquement une fois ses conditions remplies : vérifications passées, relectures requises obtenues, aucun conflit restant. Pour un opérateur solitaire qui fait tourner des agents, la fusion automatique est très séduisante. Le travail des agents arrive, ses vérifications tournent, et si elles passent, il est fusionné sans que vous leviez le petit doigt. La chaîne de livraison tourne pendant votre sommeil. C’est aussi une façon de livrer des choses que vous n’avez pas regardées, et cela mérite donc réflexion.

La question n’est pas de savoir si la fusion automatique est bonne ou mauvaise. C’est de savoir quelles modifications peuvent en bénéficier. La réponse dépend de deux choses : le risque de la modification et la solidité des vérifications. Les modifications à faible risque dotées de vérifications solides sont de bonnes candidates. Les modifications à risque élevé, ou dont les vérifications sont faibles, ne le sont pas. La décision est une bifurcation : soit la modification est assez sûre pour être fusionnée sur la seule foi de ses vérifications, soit elle demande une fusion humaine après relecture.

Qu’est-ce qui rend une modification peu risquée ? Elle touche une zone bien couverte par les tests. Elle est facile à annuler. Elle n’implique ni argent, ni sécurité, ni données personnelles, ni rien dont les utilisateurs dépendent de façon critique. C’est le genre de modification qui s’est bien passé de nombreuses fois auparavant. Les mises à jour de dépendances qui passent la suite de tests complète, les corrections de documentation, les petits remaniements dans du code bien testé et les modifications de contenu sur des pages peu fréquentées sont des candidates typiques.

La fusion automatique ne supprime pas la relecture. Elle la déplace dans les vérifications, qui ont donc intérêt à être bonnes.

Qu’est-ce qui rend des vérifications solides ? Elles échoueraient réellement si la modification était fausse. Une suite de tests qui couvre les chemins principaux et les cas limites. Un build qui casserait sur une erreur de type. Une vérification visuelle qui repérerait une mise en page cassée. Si vous n’êtes pas sûr que les vérifications attraperaient une mauvaise modification, la fusion automatique n’est qu’une fusion sans relecture, ce qui est un nom poli pour l’espoir.

Fixez les conditions explicitement. La plupart des plateformes permettent d’exiger le succès de certaines vérifications, d’exiger des étiquettes ou d’exiger que seuls certains chemins soient modifiés. Servez-vous-en pour faire appliquer votre politique au lieu de compter sur votre mémoire. Un schéma courant consiste à n’autoriser la fusion automatique que pour les pull requests portant une étiquette précise, apposée par vous ou par une recette de confiance, et seulement quand chaque vérification requise passe. Les modifications qui touchent des chemins sensibles, comme le code de paiement ou la configuration, peuvent être entièrement exclues.

Relisez après coup le travail fusionné automatiquement, au moins brièvement. La fusion automatique signifie que vous n’étiez pas dans la boucle au moment de la fusion, pas que vous ne devez jamais regarder. Un rapide coup d’œil, lors de la revue du matin, à ce qui a été fusionné pendant la nuit vous tient au courant de l’évolution de la base de code et vous permet de repérer tout motif de problèmes avant qu’il ne devienne une crise. Si quelque chose de mauvais finit un jour par être fusionné automatiquement, traitez-le comme un incident : déterminez quelle condition aurait dû l’arrêter, et resserrez-la.

Cette semaine, écrivez votre politique de fusion automatique en une phrase ou deux : quelles modifications peuvent être fusionnées automatiquement et quelles vérifications doivent passer. Si vous n’utilisez pas encore la fusion automatique, choisissez une catégorie sûre pour commencer. Si vous l’utilisez, vérifiez que vos réglages réels correspondent à la politique. Souvent, ce n’est pas le cas, et l’écart est précisément l’endroit par où quelque chose finira par se faufiler.

Des vérifications dignes de confiance

Toute chaîne de livraison a des vérifications : tests, builds, linters, vérificateurs de types, comparaisons visuelles, vérificateurs de liens, tout ce dont le projet a besoin. Avec le temps, la plupart des projets en accumulent beaucoup. La question qui compte n’est pas combien de vérifications vous avez, mais à combien vous faites confiance : combien échoueraient réellement si quelque chose d’important tournait mal. Ce sont les vérifications qui mordent. Elles, et elles seules, constituent la vraie barrière.

Commencez par distinguer les vérifications qui mordent de celles qui se contentent d’exister. Une vérification qui mord a attrapé quelque chose de réel ces derniers mois, ou vous êtes sûr qu’elle le ferait. Une vérification qui se contente d’exister passe toujours, et vous ne savez pas trop ce qu’elle attraperait. Une vérification capricieuse, qui échoue parfois sans raison, est pire qu’inutile, car elle vous apprend à ignorer les échecs et à relancer jusqu’à obtenir du vert. Chaque catégorie demande un traitement différent.

Les vérifications qui mordent doivent être obligatoires : pas de fusion sans elles, automatique ou non. Celles qui se contentent d’exister doivent être examinées. Certaines valent la peine d’être gardées parce qu’elles protègent contre des problèmes rares mais graves. D’autres sont du bruit et peuvent être supprimées, ce qui rend la chaîne plus rapide et le signal plus clair. Les vérifications capricieuses doivent être corrigées ou désactivées immédiatement. Une vérification qui crie au loup sape toutes les autres, car elle vous apprend que le rouge ne signifie pas toujours qu’il y a un problème.

Une barrière n’est solide que par les vérifications auxquelles vous croiriez vraiment.

Les agents peuvent aider à renforcer les vérifications, et c’est l’un des meilleurs usages de la capacité d’agents inemployée. Demandez à un agent d’examiner un module important et de proposer des tests pour ses cas limites. Demandez-lui d’introduire délibérément un petit bug et de voir si les tests existants l’attrapent ; s’ils ne l’attrapent pas, vous avez trouvé une lacune. Demandez-lui de débusquer les tests capricieux en lançant la suite plusieurs fois et en comparant les résultats. Chacune de ces démarches transforme une vague confiance dans vos vérifications en une confiance mesurée.

Prêtez une attention particulière aux vérifications qui portent sur ce qui compte le plus. Si la chose la plus importante que fait votre projet est de calculer correctement des factures, les vérifications sur le calcul des factures doivent être les plus solides dont vous disposez, avec des tests pour chaque cas limite imaginable. Si la chose la plus importante est qu’une page se charge vite pour les utilisateurs aux connexions lentes, il doit exister une vérification qui échouerait si ce n’était pas le cas. Les vérifications doivent refléter les risques, et les plus gros risques méritent les crocs les plus acérés.

Pour le travail hors code, les vérifications prennent une autre forme mais le principe tient. Une recette de rédaction d’e-mails clients peut inclure une vérification que chaque chiffre a une source. Une recette de publication de billets peut inclure une vérification que chaque lien fonctionne et que chaque image a un texte descriptif. Ce sont des vérifications au même sens : des choses qui doivent passer avant la livraison, et qui attraperaient un vrai problème.

Cette semaine, listez chaque vérification de la chaîne de livraison d’un projet et marquez chacune comme « mord », « existe » ou « capricieuse ». Corrigez ou supprimez les capricieuses. Pour la partie la plus importante du projet, demandez à un agent d’essayer de faire passer un petit bug entre les mailles. S’il y parvient, vous avez trouvé la prochaine vérification à écrire.

Des passes numérotées

Les gros travaux n’ont pas besoin d’être faits en une seule tentative héroïque. Ils peuvent se faire en passes : une première version qui trouve la bonne forme, une deuxième qui remplit le détail, une troisième qui peaufine. Chaque passe est une unité complète et relisible avec son propre numéro, et chacune s’appuie sur la précédente. C’est ainsi que beaucoup d’écrivains, de designers et d’ingénieurs ont toujours travaillé, et cela convient à merveille au travail des agents.

La clé est de numéroter les passes et de donner à chacune un objet distinct. Passe un : structure et squelette, tout est présent mais brut. Passe deux : substance, chaque partie correctement remplie. Passe trois : qualité, cas limites traités, langue resserrée, détails vérifiés. Dites à l’agent à quelle passe il en est et à quoi elle sert. Un agent à qui l’on demande la passe un ne gaspillera pas d’effort en finitions. Un agent à qui l’on demande la passe trois ne restructurera pas.

Les passes numérotées facilitent grandement la relecture. Vous relisez la passe un pour la forme seulement, avec la première moitié de la relecture en deux passes. Vous relisez la passe deux pour la substance. Vous relisez la passe trois pour la qualité et le goût. À chaque étape, vous cherchez un seul type de problème, ce qui est bien moins fatigant et bien plus fiable que de chercher tous les types de problèmes à la fois. Et comme chaque passe est relue avant que la suivante ne commence, les problèmes sont attrapés au moment où ils coûtent le moins.

Ne demandez pas la perfection. Demandez la passe un, puis la passe deux.

Les passes rendent aussi la progression visible. Au lieu d’un gros travail situé quelque part entre commencé et fini, vous avez une trace claire : passe un faite, passe deux en cours. Cela tient parfaitement dans le registre et dans les notes de passation. Cela permet aussi de s’arrêter au bon moment. Certains travaux n’ont besoin que de deux passes. D’autres en demandent quatre. Les numéroter vous permet de décider, après chaque relecture, si une passe de plus en vaut la peine.

Gardez chaque passe. Enregistrez la passe un avant de commencer la passe deux, que ce soit comme version dans un dépôt, comme fichier numéroté ou comme copie dans le dossier du projet. Si la passe deux tourne mal, vous pouvez revenir à la passe un sans rien perdre. Si vous voulez comprendre plus tard comment le travail a évolué, les passes racontent l’histoire. Il arrive que les agents rendent une passe ultérieure moins bonne qu’une précédente, surtout quand on leur demande d’améliorer quelque chose qui était déjà bon, et avoir la version antérieure sous la main permet de s’en apercevoir et de rattraper le coup facilement.

Les passes fonctionnent pour presque tous les types de production. Un rapport : plan, brouillon, révision. Une fonctionnalité : modèle de données, logique, interface. Un design : mise en page, contenu, finition visuelle. Un jeu de données : schéma, remplissage, validation. Dans chaque cas, la même discipline s’applique : nommer la passe, énoncer son objet, la relire pour cet objet, la conserver, puis entamer la suivante.

Cette semaine, prenez un travail conséquent et menez-le en passes explicitement numérotées. Briefez chaque passe séparément avec son objet. Relisez chacune pour le type de problème qui lui est propre. Gardez chaque version. À la fin, comparez le déroulement de ce travail avec celui d’une grande tentative unique telle que vous la vivez d’habitude. La différence tient généralement moins à la qualité finale, qui peut être semblable, qu’à la sérénité du chemin parcouru.

Livrer vaut mieux que parfaire, en général

Il existe un vieux principe, cher à quiconque a déjà livré quoi que ce soit : mieux vaut livrer que parfaire. Une bonne chose dans le monde vaut plus qu’une chose parfaite dans un dossier de brouillons. Les utilisateurs peuvent réagir à ce qui existe ; ils ne peuvent pas réagir à ce que vous êtes encore en train de polir. Les agents rendent ce principe plus pertinent que jamais, car l’écart entre « assez bon » et « parfait » est souvent bien plus petit qu’il n’en a l’air, et le temps passé à le combler serait généralement mieux employé à la chose suivante.

Mais le principe comporte un astérisque, et les opérateurs qui l’oublient l’apprennent à leurs dépens. Livrer vaut mieux que parfaire quand le coût de l’erreur est faible et le coût de l’annulation réduit. Quand l’un des deux coûts est élevé, le calcul change, et un peu plus de finition avant de livrer n’est pas du perfectionnisme mais de la prudence.

Pensez-y sur deux axes. L’un est le degré de finition qu’a reçu le travail. L’autre est le coût de son annulation s’il se révèle faux. Le travail facile à annuler peut partir avec une finition modeste : si quelque chose cloche, on corrige demain. Le travail coûteux à annuler, un e-mail à tous les clients, une modification du calcul de l’argent, une déclaration publique, une suppression, a besoin de davantage de finition avant de partir. Le coin où il faut livrer tout de suite est celui du faible coût d’annulation et de la finition suffisante, et c’est là que se trouve la plupart du travail.

Livrez ce que vous pouvez reprendre. Peaufinez ce que vous ne pouvez pas reprendre.

Le piège des perfectionnistes est de traiter chaque travail comme s’il était coûteux à annuler. Un billet de blog peut être modifié après publication. Une page peut être corrigée à la livraison suivante. Une fonctionnalité peut être améliorée la semaine prochaine. Aucune de ces choses n’a besoin d’être parfaite pour partir ; elles doivent être bonnes et correctes. Les retenir pour les peaufiner n’est pas de la prudence. C’est du retard, et le retard a ses propres coûts.

Le piège des livreurs est l’inverse : traiter tout comme facile à annuler parce que la plupart des choses le sont. Un opérateur fortement enclin à livrer, armé d’agents rapides, peut expédier quelque chose d’irréversible avec la même désinvolture qu’une broutille. L’habitude qui prévient cela consiste à étiqueter le travail selon son coût d’annulation avant la relecture, dans le cadre du brief. Coût d’annulation faible : relire légèrement, livrer vite. Coût d’annulation élevé : relire à fond, envisager une livraison progressive, dormir dessus si possible.

Il existe une voie médiane pour le travail coûteux à annuler mais qui doit partir : le rendre moins coûteux à annuler. Livrez d’abord à un public restreint. Placez-le derrière un interrupteur que vous pouvez éteindre. Envoyez l’e-mail à vous-même et à un collègue avant de l’envoyer à la liste. Beaucoup d’actions irréversibles peuvent être rendues en partie réversibles avec un peu de réflexion, et cette réflexion coûte souvent moins cher qu’un surcroît de finition.

Cette semaine, étiquetez tout ce que vous livrez avec son coût d’annulation : faible ou élevé. Livrez les faibles dès qu’ils sont bons et corrects. Accordez aux élevés une relecture particulièrement attentive et, si possible, un chemin de retour. Remarquez combien les faibles avancent plus vite quand vous cessez de les traiter comme les élevés.

La note de livraison

Chaque livraison mérite une note. Pas une longue, et pas nécessairement publique, mais une courte trace écrite au moment de la livraison, qui dit ce qui est parti, pourquoi, ce qui pourrait mal tourner et comment l’annuler. Cela prend deux minutes. Ce sont les deux minutes les plus utiles que vous puissiez passer au moment de livrer, et elles sont presque toujours sautées.

La note comporte quatre parties. Quoi : la modification, en une phrase qu’un utilisateur ou un futur vous comprendrait. Les exports incluent désormais les éléments archivés. Pourquoi : la raison, brièvement. Les utilisateurs demandaient un historique complet. Risque : ce qui pourrait mal tourner, selon votre estimation honnête. Les gros comptes pourraient voir leurs exports ralentir. Annulation : comment revenir en arrière si besoin. Annuler la fusion ; aucune modification de données en jeu. Quatre lignes, rassemblées autour de la livraison comme les rayons autour d’un moyeu.

Ce sont les lignes de risque et d’annulation qui rapportent. Écrire ce qui pourrait mal tourner vous oblige à y penser un instant, ce qui révèle parfois un problème avant la livraison. Et écrire comment annuler signifie que si quelque chose tourne mal, à une heure malcommode, vous n’avez pas à improviser le rétablissement sous pression. Vous lisez la note et vous la suivez. Les opérateurs qui ont dû concevoir un retour arrière à minuit avec un client inquiet au bout du fil adoptent généralement les notes de livraison très vite après.

Le moment d’écrire l’annulation, c’est avant d’en avoir besoin.

Où ranger les notes ? Là où vous les trouverez quand quelque chose tournera mal. Un fichier de journal des modifications dans le projet, complété à chaque livraison, fonctionne bien. Une section dans la description de la pull request aussi, ou une entrée du carnet étiquetée du nom du projet. Pour les livraisons que voient les utilisateurs, un journal des modifications public est un document distinct et utile, mais il ne remplace pas la note privée, qui peut être plus franche sur les risques.

Les agents peuvent rédiger les notes de livraison à partir de la pull request et du diff, et c’est un usage judicieux. Mais la ligne de risque, en particulier, demande votre attention, car elle repose sur un savoir que l’agent n’a peut-être pas : quels clients sont sensibles à quelles modifications, ce qui a déjà mal tourné, ce qui vous inquiète en silence. Retouchez le brouillon avant de vous y fier.

Les notes de livraison nourrissent aussi vos revues plus longues. À la fin d’une semaine ou d’un trimestre, relire les notes de livraison donne une trace précise et datée de ce qui a été livré, des risques acceptés et de ceux qui se sont concrétisés. C’est un excellent matériau d’apprentissage : vous pouvez voir si vos estimations de risque ont tendance à être trop pessimistes ou trop optimistes, et ajuster.

Il y a aussi un modeste bénéfice de discipline. Si vous n’arrivez pas à écrire une ligne « quoi » sensée, la livraison regroupe probablement trop de choses. Si vous ne pouvez pas écrire l’annulation, la livraison est peut-être plus irréversible que vous ne le pensiez. La note est une dernière vérification déguisée en paperasse.

Cette semaine, écrivez une note de livraison en quatre lignes pour tout ce que vous livrez. Gardez-les à un seul endroit par projet. À la clôture du vendredi, relisez-les. Remarquez quels risques vous avez nommés, lesquels se sont produits et lesquels non. Ce petit exercice fera de vous un meilleur juge du risque plus vite que n’importe quelle lecture sur le sujet.

Le retour arrière est une fonctionnalité

Des choses tournent mal après une livraison. Pas souvent, si vous livrez petit et relisez bien, mais parfois, et quand cela arrive, la question la plus importante est la vitesse à laquelle vous pouvez remettre les choses comme elles étaient. Une activité capable de revenir en arrière en une minute peut se permettre de livrer avec audace. Une activité qui ne le peut pas doit livrer nerveusement, lentement et rarement. Le retour arrière n’est pas une procédure d’urgence. C’est une fonctionnalité d’un processus de livraison sain, et il faut le concevoir, le tester et le maintenir en état de marche.

La séquence voulue est courte. Vous livrez une modification. Vous, ou une vérification, repérez un problème. Vous revenez en arrière. Le service est rétabli, et alors seulement vous enquêtez. L’ordre compte. L’instinct, quand quelque chose casse, est de diagnostiquer sur place et de corriger vers l’avant, parce que vous êtes à peu près sûr de savoir ce qui ne va pas et que la correction est probablement petite. Parfois, ça marche. Souvent, la correction introduit un second problème, et vous voilà à déboguer sous pression, des utilisateurs touchés. Revenir en arrière d’abord retire la pression. Vous pouvez enquêter calmement, tout fonctionnant.

Pour du code dans un dépôt, le retour arrière est généralement simple : annuler la fusion et redéployer. Assurez-vous de savoir exactement comment faire pour chaque projet, et que cela fonctionne réellement. Certaines configurations de déploiement rendent l’opération triviale ; d’autres la rendent étonnamment malaisée. Découvrez-le avant d’en avoir besoin. Une procédure de retour arrière jamais essayée est une hypothèse, pas une procédure.

Si vous ne pouvez pas l’annuler, vous ne l’avez pas livré. Vous vous y êtes engagé.

Certaines modifications sont plus difficiles à annuler que d’autres, et elles méritent une réflexion supplémentaire avant livraison. Les modifications de base de données qui suppriment ou transforment des données ne peuvent pas simplement être annulées, car les anciennes données ont disparu. Les e-mails et messages, une fois envoyés, ne peuvent pas être rappelés. Les modifications dont d’autres systèmes dépendent peuvent laisser ces systèmes dans un état étrange si on les annule. Pour celles-là, planifiez le retour arrière avant la livraison : sauvegardez les données, faites la modification de façon rétrocompatible, ou échelonnez la livraison pour que seul un public restreint la voie d’abord.

Les agents peuvent aider à planifier le retour arrière. Dans le brief de toute modification risquée, demandez à l’agent de décrire comment la modification pourrait être annulée et ce qui serait perdu. Si la réponse est compliquée ou implique une perte de données, c’est le signal qu’il faut restructurer la modification avant de la livrer. Beaucoup d’agents écriront aussi, si on le leur demande, les étapes de retour arrière dans la description de la pull request, ce qui les place exactement là où vous regarderez quand vous en aurez besoin.

Après tout retour arrière, écrivez une note d’incident, dont une partie ultérieure de ce livre traite. Le retour arrière a rétabli le service ; la note veille à ce que le même problème soit moins probable la prochaine fois. Ensemble, ils transforment un mauvais moment en amélioration.

Cette semaine, choisissez votre projet le plus important et faites un exercice de retour arrière. Livrez une modification inoffensive, puis annulez-la, en chronométrant l’ensemble et en notant toute étape malaisée. Corrigez les étapes malaisées. Puis écrivez la procédure dans le runbook du projet. Vous n’en aurez probablement jamais besoin dans l’urgence. Si c’est le cas, vous serez content qu’il s’agisse d’une fonctionnalité plutôt que d’une improvisation.

Ne jamais commiter de secrets

La plupart des règles de ce livre sont des réglages par défaut, des points de départ raisonnables à adapter à votre propre activité. Celle-ci, non. Ne commitez jamais de secrets. Ni dans un dépôt, ni dans un fichier de mémoire, ni dans un document partagé, ni dans un brief, ni dans une description de pull request, ni dans un carnet synchronisé dans le cloud. Mots de passe, clés d’accès, jetons, chaînes de connexion privées : aucun n’a sa place là où l’on stocke du code ou des notes.

La raison est simple. Les dépôts et les notes sont conçus pour être copiés, partagés, synchronisés et conservés pour toujours. Une fois qu’un secret figure dans l’historique d’un dépôt, le retirer de la version actuelle ne le retire ni de l’historique, ni des clones faits entre-temps, ni d’aucun service qui l’a indexé. Un secret commité doit être présumé vu. L’intersection entre votre code et un secret n’est pas un lieu de stockage. C’est un incident qui attend d’être découvert.

Les agents font monter les enjeux de deux façons. D’abord, ils travaillent vite et touchent beaucoup de fichiers, si bien qu’un secret collé dans un brief ou trouvé dans un fichier de configuration peut finir dans un commit sans que vous le remarquiez. Ensuite, ils sont serviables, et un agent qui débogue un problème de connexion peut fort bien placer un identifiant directement dans le code pour tester, puis oublier de l’enlever.

Un secret dans un dépôt n’est plus un secret. C’est un compte à rebours.

Les défenses s’empilent. Gardez les secrets dans un vrai gestionnaire de secrets, dans des variables d’environnement ou dans la gestion des secrets que fournit votre plateforme, et chargez-les à l’exécution. Ne collez jamais la valeur d’un secret dans un brief ; dites à l’agent où le secret est configuré et laissez-le utiliser le mécanisme. Assurez-vous que les fichiers contenant des secrets locaux sont exclus du contrôle de version, et vérifiez-le à la mise en place de tout nouveau projet. Activez l’analyse des secrets sur vos dépôts partout où la plateforme la propose, pour qu’un secret commité soit attrapé au moment du push plutôt que des mois plus tard. Et placez une consigne permanente dans la mémoire de chaque projet : les identifiants et jetons ne doivent jamais être écrits dans le code, les notes ou les commits.

Si un secret est quand même commité, agissez immédiatement et dans le bon ordre. Changez d’abord le secret, pour que la valeur exposée ne fonctionne plus. Retirez-le ensuite du dépôt et, si c’est pertinent, de l’historique. Puis vérifiez si la valeur exposée a été utilisée par quelqu’un d’autre pendant qu’elle était valide. Enfin, écrivez une note d’incident et ajoutez le garde-fou qui l’aurait attrapé. Changer d’abord le secret est l’étape cruciale. Effacer la ligne sans changer le secret, c’est changer l’étiquette de la serrure sans changer la serrure.

C’est la seule règle de ce livre qui mérite de devenir un réflexe. Chaque fois que vous êtes sur le point de coller quelque chose dans un brief, une note ou un fichier, demandez-vous : est-ce un secret ? Si oui, arrêtez-vous et trouvez-lui sa vraie place.

Cette semaine, activez l’analyse des secrets sur chaque dépôt qui vous appartient, vérifiez que les fichiers de secrets locaux sont exclus du contrôle de version, et ajoutez la consigne permanente à chaque fichier de mémoire. Puis changez tout ce dont vous n’êtes pas absolument sûr que cela n’a jamais été commité. C’est un après-midi de travail ennuyeux. Il ferme la seule porte qui ne devrait jamais être ouverte.

Fini veut dire en ligne

Quand une chose est-elle finie ? Les opérateurs répondent différemment à cette question, et la réponse détermine en silence la quantité de travail réellement livrée. Certains considèrent le travail fini quand l’agent annonce qu’il a terminé. D’autres quand la relecture est passée. D’autres quand la pull request est fusionnée. La réponse la plus utile, celle que recommande ce livre, est plus stricte : fini veut dire en ligne, devant les personnes à qui c’était destiné, et vérifié là.

La chaîne qui mène du travail achevé au travail fini compte plusieurs maillons, et chacun est un endroit où les choses calent. Le travail est fusionné mais pas déployé, parce que le déploiement est une étape séparée que personne n’a déclenchée. Il est déployé mais pas en ligne, parce qu’il se trouve derrière un interrupteur jamais allumé, ou sur un serveur de préproduction que personne ne visite. Il est en ligne mais pas vérifié, parce que vous avez supposé que s’il s’était déployé, il devait fonctionner. Chaque calage laisse le travail dans un état qui paraît fini et ne l’est pas, et c’est un état dans lequel il est étonnamment confortable de laisser les choses.

Le dernier maillon, « vérifié », est celui qui compte le plus. Une fois le travail en ligne, regardez-le là. Ouvrez la page sur le vrai site. Utilisez la fonctionnalité comme le ferait un utilisateur. Confirmez que l’e-mail est arrivé dans une vraie boîte de réception. Vérifiez que les données apparaissent dans le vrai tableau de bord. Cela prend une minute ou deux et attrape toute une classe de problèmes qu’aucune vérification avant livraison ne peut attraper : différences de configuration entre environnements, cache, droits d’accès, services tiers qui se comportent autrement en production. Un travail qui a passé toutes les vérifications avant livraison peut encore échouer dans le monde réel, et la seule façon de le savoir est de regarder.

Fusionné est une étape. En ligne et vérifié est un résultat.

Définir « fini » ainsi change les comportements en amont. Quand vous savez que fini veut dire en ligne et vérifié, vous briefez en pensant à la livraison : comment cela sera-t-il déployé, comment sera-t-il activé, comment le vérifierai-je en production ? Vous remarquez les frictions de déploiement, car chaque déploiement en souffrance empêche quelque chose d’être fini. Vous planifiez la vérification, au lieu de la supposer. Et le registre devient plus honnête, car les projets ne sont pas marqués finis tant qu’ils ne le sont pas vraiment.

Cela change aussi la façon de compter. Le chapitre sur le débit suggérait de compter ce qu’on finit. Avec « fini » signifiant en ligne et vérifié, le compte devient celui des choses qui ont réellement atteint des gens. C’est un nombre plus petit que celui des fusions ou des achèvements, et c’est le seul qui reflète ce que votre activité a fait pour quelqu’un.

Pour le travail qui ne se déploie pas, le principe se transpose. Un document est fini quand la personne à qui il était destiné l’a reçu et peut l’ouvrir. Un jeu de données est fini quand il est chargé là où il sera utilisé et qu’un échantillon a été vérifié. Un design est fini quand il est entre les mains de celui qui va le construire ou le publier. Dans chaque cas, « fini » se définit au bout de la chaîne, pas à votre bureau.

Cette semaine, changez votre définition de « fini » pour « en ligne et vérifié », et appliquez-la à tout. Remarquez combien de choses que vous auriez auparavant dites finies sont coincées à un maillon antérieur. Poussez chacune jusqu’au bout et regardez-la là. Certaines auront besoin d’une petite correction que vous auriez autrement ratée. Toutes seront enfin finies.

La revue hebdomadaire

La journée a sa revue et sa clôture. La semaine demande quelque chose de plus ample : une heure, une fois par semaine, pendant laquelle vous prenez du recul sur le rythme quotidien et regardez l’activité dans son ensemble. La revue hebdomadaire est l’endroit où vous remarquez ce que les journées ne peuvent pas vous montrer, le projet qui a discrètement calé, le motif récurrent des problèmes, l’engagement oublié, et où vous décidez à quoi servira la semaine suivante.

La revue compte quatre mouvements. Rassembler : recueillir tout ce qui s’est passé dans la semaine. Le registre, le carnet, les notes de livraison, la file des idées en attente, les fils encore ouverts. Passer en revue : tout lire, en cherchant ce qui a bien marché, ce qui a mal marché et ce qui n’a pas bougé. Décider : prendre les décisions que la semaine a fait émerger, sur les projets à pousser, ceux à mettre en sommeil, les fils à fermer, les recettes à corriger. Planifier : esquisser la semaine suivante, pas en détail, mais en termes des deux ou trois résultats qui en feraient une bonne semaine.

La décision en est le cœur. Une revue hebdomadaire qui rassemble et lit mais ne décide pas est une heure de réflexion agréable sans effet. Veillez à ce que la revue produise des décisions, écrites, au moins quelques-unes chaque semaine. Mettre le plan de formation en sommeil jusqu’au trimestre prochain. Fermer les trois fils égarés sur l’ancienne migration. Ajouter la vérification du fichier vide à la recette d’import. Résultat principal de la semaine prochaine : livrer la fonctionnalité d’export. Ce sont ces phrases qui transforment la réflexion en pilotage.

La journée vous fait avancer. La semaine vous garde dans la bonne direction.

Choisissez un horaire fixe et protégez-le. Beaucoup d’opérateurs préfèrent la fin de la semaine de travail, quand la semaine est fraîche dans l’esprit et que la revue peut servir aussi de vraie clôture avant le week-end. D’autres préfèrent le début de semaine, quand ils sont reposés et que planifier vient naturellement. Les deux marchent. Ce qui ne marche pas, c’est de faire la revue quand on trouve une heure de libre, car on n’en trouve jamais.

Les agents peuvent assurer une bonne part du rassemblement. Une bonne recette demande à un agent de lire les entrées du carnet de la semaine, le registre, les notes de livraison et les fils ouverts, et de produire un court condensé : ce qui a été livré, ce qui a calé, ce qui vous attend, ce qui semble périmé. Ce condensé rend la revue plus rapide et plus complète. Il ne remplace pas votre lecture des matériaux sous-jacents, en particulier du carnet, où vos propres mots en révèlent souvent plus que n’importe quel résumé.

La revue hebdomadaire entretient aussi la machine. C’est le moment naturel pour vérifier que le registre est à jour, élaguer la file, fermer les fils égarés, jeter un œil aux fichiers de mémoire à la recherche de quoi que ce soit de périmé, et s’assurer que rien n’a été laissé dans un état ambigu. Dix minutes de rangement par semaine évitent la lente accumulation de désordre qui demanderait sinon une journée entière à déblayer.

Cette semaine, réservez une heure pour la revue hebdomadaire et menez-la selon les quatre mouvements. Rassembler, passer en revue, décider, planifier. Écrivez au moins cinq décisions. La semaine prochaine, commencez la revue en vérifiant si ces décisions ont été appliquées. Cette boucle toute simple, décider puis vérifier, est ce qui fait de la revue hebdomadaire un moteur plutôt qu’un rituel.

Faire place nette

Au fil d’une semaine, les boucles ouvertes s’accumulent. Un fil commencé et pas terminé. Un message auquel vous comptiez répondre. Une idée dans la file. Une relecture à moitié faite. Une pull request en attente. Une note à vous-même pour vous pencher sur quelque chose. Chacune est petite, et chacune reste dans un coin de votre tête à consommer une parcelle d’attention. Ensemble, elles produisent le bourdonnement sourd et constant des choses non traitées, l’une des sensations les plus fatigantes que puisse connaître un opérateur.

Faire place nette, c’est prendre chaque boucle ouverte, une fois par semaine, et la traiter de l’une de quelques façons. La fermer, en la terminant si cela prend deux minutes. La trancher, en choisissant ce qui se passera ensuite et en l’écrivant. La mettre en sommeil, avec une note et une condition. Ou l’abandonner, en acceptant qu’elle ne se fera pas et en la laissant partir. Le but n’est pas de tout finir. C’est de s’assurer que rien ne reste dans l’état d’indécision.

L’entonnoir est raide. Vous commencez avec toutes les boucles ouvertes que vous pouvez trouver, et il y en aura plus que prévu. La plupart, à l’examen, ne demandent qu’une décision rapide : ce fil peut fermer, cette idée peut être abandonnée, ce message appelle une réponse d’une ligne. Un plus petit nombre demande une vraie réflexion. Tout en bas, chaque boucle a été soit dégagée, soit dotée d’une suite claire, et le bourdonnement se tait.

Une boucle ouverte coûte de l’attention, qu’on travaille dessus ou non. Une boucle tranchée ne coûte rien.

Trouver les boucles représente la moitié du travail. Regardez aux endroits évidents : le registre, la file, les fils ouverts, les dossiers de brouillons, les pull requests, votre boîte de réception. Puis regardez aux endroits moins évidents : le carnet, où vous avez peut-être écrit mardi à creuser absolument sans jamais le faire ; la fin des comptes rendus d’agents, où les questions ouvertes sont listées puis oubliées ; les coins de votre bureau, physique ou numérique. Beaucoup d’opérateurs tiennent une courte liste des endroits où regarder, ce qui fait de la recherche des boucles une routine plutôt qu’un exercice de mémoire.

Soyez résolu dans l’abandon. Certaines boucles ne se feront jamais, et c’est très bien, à condition de l’admettre. Une idée qui a dormi un mois dans la file sans jamais entrer dans un plan hebdomadaire ne se réalisera probablement pas. Abandonnez-la. Un fil qui explorait une chose dont vous ne vous souciez plus peut fermer. Abandonner n’est pas échouer. C’est décider, et ce sont les décisions qui font place nette.

Les agents peuvent aider à trouver les boucles. Demandez à l’un d’eux de lister tous les fils ouverts avec leur date de dernière activité, toutes les pull requests en brouillon, toutes les questions restées sans réponse dans les comptes rendus récents et tous les éléments de la file vieux de plus de deux semaines. Cette liste est un bon point de départ. Mais la décision vous revient, et elle se prend au mieux vite, presque sèchement, sans se torturer sur chaque élément.

Cette semaine, dans le cadre de la revue hebdomadaire, faites place nette. Trouvez chaque boucle ouverte, et pour chacune, fermez, tranchez, mettez en sommeil ou abandonnez. Comptez combien vous en aviez au départ et combien restent indécises à la fin. L’objectif pour le second nombre est zéro. Vous ne l’atteindrez peut-être pas du premier coup. Vous remarquerez le silence quand vous vous en approcherez.

Compter ce qui a été livré

Les opérateurs équipés d’agents peuvent perdre de vue ce qu’ils ont réellement accompli. Il se passe tant de choses, tant de fils tournent, tant de production arrive, qu’en fin de semaine il est sincèrement difficile de dire ce qui a changé. Cela compte plus qu’il n’y paraît, car un opérateur qui ne sait pas ce qui a été livré ne peut pas juger si l’activité fonctionne, et tend à compenser l’incertitude en lançant davantage de choses.

Le remède est un décompte hebdomadaire honnête. Non pas des heures travaillées, des fils lancés ou des jetons consommés, mais des choses livrées : en ligne et vérifiées, devant les personnes à qui elles étaient destinées. Tenez le décompte dans le carnet ou le registre, avec une ligne par élément. En fin de semaine, lisez la liste.

Il est utile de voir le décompte comme le sommet d’une pile. Tout en bas, tout ce qui a été commencé : la couche la plus large, et la moins significative. Au-dessus, tout ce que les agents ont fini, qui est plus étroit. Au-dessus encore, tout ce qui a été fusionné ou envoyé, plus étroit encore. Au sommet, ce qui est en ligne et vérifié. Chaque couche est réelle, mais seule celle du sommet est un résultat. Beaucoup d’opérateurs, la première fois qu’ils font ce décompte, découvrent que leur couche supérieure est étonnamment mince par rapport aux couches en dessous.

Comptez ce qui est fini. Ce qui est commencé se débrouillera bien tout seul.

Cette découverte est utile plutôt que déprimante. Une couche supérieure mince sur un milieu épais signifie que le travail se coince entre fini et livré, généralement au déploiement, à la relecture finale ou au moment d’envoyer effectivement quelque chose. Une couche supérieure mince sur une base épaisse signifie qu’on commence trop et qu’on ne mène pas assez à terme. Chaque motif suggère un remède précis, et le décompte vous dit quel motif est le vôtre.

Le décompte est aussi bon pour le moral, de la bonne façon. Travailler seul peut isoler, et sans collègues pour remarquer votre travail, il est facile d’avoir l’impression de ne pas accomplir grand-chose. Une liste écrite de ce qui a été livré, lue en fin de semaine, est une preuve concrète du contraire. Les semaines où la liste est courte, c’est une invitation à se demander pourquoi, sans culpabilité, comme on s’interrogerait sur une machine qui tourne en dessous de sa capacité.

Gardez les décomptes. Sur un trimestre, ils deviennent une trace de la production réelle de l’activité, bien plus utile que votre souvenir de celle-ci. À la revue trimestrielle, relire douze semaines de listes de livraisons révèle des tendances qu’aucune semaine isolée ne montre : quels types de travail sont livrés de façon fiable, lesquels calent, comment le volume a évolué, si vos estimations de capacité sont justes.

Soyez strict sur ce qui compte. Une chose est livrée si elle est en ligne et vérifiée, pas si elle y est presque, fusionnée mais pas déployée, ou renvoyée à l’agent pour une dernière révision. La rigueur garde le décompte honnête, et les décomptes honnêtes sont les seuls qui méritent d’être tenus.

Cette semaine, tenez une liste de livraisons, une ligne par élément, au sens strict. À la revue hebdomadaire, lisez-la et comparez-la à ce que vous avez commencé. Regardez l’écart entre les couches. C’est dans cet écart que se cache la prochaine amélioration de votre activité.

La revue trimestrielle

La revue hebdomadaire maintient l’activité dans la bonne direction. La revue trimestrielle se demande si c’est seulement la bonne direction. Une fois tous les trois mois, prenez une demi-journée, idéalement loin du bureau habituel, et regardez l’activité entière d’assez loin pour en voir la forme. C’est là que vous changez de cap délibérément plutôt que par dérive.

La revue trimestrielle tourne autour de quatre questions posées à chaque partie de l’activité. Que dois-je continuer, parce que cela marche ? Que dois-je arrêter, parce que cela ne mérite plus sa place ? Que dois-je commencer, parce que quelque chose manque ? Et que dois-je changer, parce que c’est juste en principe mais faux en pratique ? Posez-les aux projets du registre, aux recettes de la bibliothèque, aux outils de la boîte à outils, aux habitudes du rythme quotidien. Les réponses sont les décisions du trimestre.

Commencez par les traces. Lisez les listes de livraisons de chaque semaine, le journal des décisions, les notes d’incident et le carnet. Cherchez des motifs. Quels projets ont le plus produit ? Lesquels ont consommé le plus d’attention pour le moins de résultat ? Quels types de travail se sont bien passés et lesquels n’ont cessé de mal tourner ? Qu’aviez-vous décidé à la dernière revue trimestrielle, et est-ce arrivé ? Cette lecture est la matière première de réponses honnêtes, et elle protège contre la tendance naturelle à se souvenir du trimestre comme meilleur ou pire qu’il ne l’a été.

La semaine demande quoi faire ensuite. Le trimestre demande quoi cesser de faire.

La question de l’arrêt est la plus difficile et la plus précieuse. Toute activité accumule des projets, des outils, des habitudes et des engagements qui avaient du sens autrefois et n’en ont plus. Ils persistent parce que mettre fin aux choses est inconfortable et les continuer facile. La revue trimestrielle est le moment d’y mettre fin délibérément. Un projet resté en sommeil tout le trimestre sans que sa condition soit remplie devrait probablement prendre fin. Un outil inutilisé depuis trois mois devrait probablement partir. Une recette qui produit sans cesse de mauvais résultats doit être corrigée ou retirée. Le chapitre suivant traite de l’art de bien mettre fin aux choses.

La question du commencement est la source des nouvelles directions. Regardez les idées en attente, la file, les manques que le trimestre a révélés. Choisissez au plus une ou deux choses nouvelles à commencer. En commencer davantage, en plus de tout ce qui continue, signifie généralement qu’aucune ne reçoit assez d’attention pour réussir.

Écrivez les décisions, brièvement, et placez-les là où la revue du trimestre suivant les trouvera. Puis faites en sorte que les revues hebdomadaires les mettent en œuvre : chaque décision devient une ligne du registre, une modification de recette ou d’habitude, et la revue hebdomadaire suit les progrès. Une revue trimestrielle dont les décisions ne sont jamais appliquées n’est qu’un agréable après-midi de réflexion. Les après-midi agréables, c’est bien. Ce n’est pas du pilotage.

Ce trimestre, réservez une demi-journée pour la revue. Lisez les traces. Posez les quatre questions à chaque projet, recette, outil et habitude. Écrivez les décisions, surtout les arrêts. Puis confiez-les aux revues hebdomadaires pour qu’elles les appliquent. Dans trois mois, relisez-les et voyez combien se sont réalisées. La proportion vous dira dans quelle mesure votre activité est pilotée, et dans quelle mesure elle se contente de bouger.

Tuer les projets avec tact

Certains projets devraient s’arrêter avant d’être terminés. Le marché a bougé, le client a changé d’avis, l’idée s’est révélée moins intéressante qu’elle n’en avait l’air, ou vous avez tout simplement mieux à faire de votre attention. Mettre fin à un projet est l’une des décisions les plus utiles que prenne un opérateur, et l’une des plus évitées, parce qu’elle ressemble à un échec. Ce n’en est pas un. C’est une taille, et une activité bien taillée pousse davantage qu’une activité envahie.

La question à poser n’est pas de savoir si le projet est bon, mais s’il vaut encore ce qu’il coûte. Chaque projet actif ou en sommeil coûte quelque chose : de l’attention dans le registre, de la culpabilité quand on le regarde, des fils à entretenir, une place qui pourrait accueillir autre chose. Si la valeur probable du projet ne justifie plus ce coût, il doit prendre fin. La réponse sera parfois on continue, et c’est très bien. Quand c’est on arrête, la question suivante est : comment ?

Arrêtez-le bien. Cela veut dire quatre choses. Terminer ou fermer chaque fil, pour que rien ne reste en marche. Écrire une courte note de clôture : ce qu’était le projet, ce qu’il a accompli, pourquoi il s’est arrêté, et tout ce qui mérite d’être gardé. Archiver les matériaux à un endroit où vous pourriez les retrouver, plutôt que de les supprimer. Et prévenir quiconque a besoin de savoir, un client, un collaborateur, les utilisateurs d’un outil, avec assez de préavis et d’explications pour qu’ils ne soient pas pris par surprise.

Bien terminer un projet est un savoir-faire. En laisser un mourir lentement est une habitude.

La note de clôture compte plus qu’il n’y paraît. Les projets qui s’arrêtent brutalement laissent derrière eux de la confusion : des fils à moitié finis, des fichiers orphelins, une vague impression d’affaire inachevée. Les projets qui s’arrêtent avec une note laissent derrière eux une trace propre. Si vous voulez un jour relancer l’idée, la note vous dit où vous en étiez et pourquoi vous avez arrêté. Si vous ne le voulez jamais, la note vous permet de cesser d’y penser, ce qui est en soi un soulagement.

Cherchez ce qui peut être récupéré. Les projets terminés contiennent souvent des pièces utiles : une recette qui a marché, un composant réutilisable, une recherche qui répond à une question ailleurs, une leçon qui mérite d’entrer en mémoire. Avant d’archiver, passez dix minutes à les extraire. Ce sont les dividendes du projet, et ils justifient souvent l’effort même quand le projet lui-même n’a pas atteint son but.

Les agents peuvent aider à la mécanique : fermer les fils, archiver les fichiers, rédiger la note de clôture, lister les pièces réutilisables. Ils ne doivent pas prendre la décision. Mettre fin à un projet est exactement le genre de jugement qui appartient à l’opérateur, car il dépend de priorités et d’engagements que vous seul pouvez peser.

Les projets les plus difficiles à arrêter sont ceux que vous avez lancés avec enthousiasme et dans lesquels vous avez beaucoup investi. Le coût irrécupérable vous tire par la manche : tant de travail, ce serait du gâchis d’arrêter maintenant. Mais le travail est dépensé dans un cas comme dans l’autre. La seule question est de savoir si l’heure suivante est mieux employée sur ce projet ou sur autre chose. Répondez-y honnêtement, et le coût irrécupérable lâche prise.

Ce trimestre, trouvez un projet qui devrait s’arrêter et arrêtez-le bien : fils fermés, note écrite, matériaux archivés, personnes prévenues. Remarquez l’effet sur le registre. Plus léger, presque certainement. Cette légèreté, c’est de l’attention qui vous est rendue.

L’énergie est le vrai budget

La façon habituelle de penser la capacité se compte en heures : combien en ai-je, comment les dépenser ? Pour un opérateur équipé d’agents, l’heure est la mauvaise unité. Les agents peuvent travailler autant d’heures qu’on veut. Ce qui limite l’activité, ce n’est pas votre temps mais votre énergie : la qualité d’attention que vous pouvez apporter aux décisions et aux relectures. Une heure d’attention affûtée et une heure d’attention embrumée sont toutes deux des heures. Ce n’est pas le même budget.

L’énergie varie au cours de la journée, de la semaine et de périodes plus longues. La plupart des gens ont quelques heures par jour pendant lesquelles ils pensent clairement, décident bien et relisent avec soin, et beaucoup plus d’heures pendant lesquelles ils peuvent faire un travail utile mais pas leur meilleur travail. Le motif exact diffère selon les personnes. Ce qui ne diffère pas, c’est que les meilleures heures sont rares et que le travail qui en a besoin est le plus précieux de l’activité.

Accordez donc le travail à l’énergie. Pensez les tâches de l’opérateur selon deux axes : la valeur qu’elles créent et l’énergie qu’elles exigent. Le travail à forte valeur et forte énergie, prendre des décisions importantes, relire des modifications risquées, écrire les briefs de tâches difficiles, a sa place dans vos meilleures heures. Le travail à faible valeur et faible énergie, ranger des fichiers, fermer des fils, répondre aux messages courants, a sa place dans les heures où vous n’êtes pas au sommet de votre forme. L’erreur la plus courante est l’inverse : consacrer la première heure affûtée de la matinée aux e-mails et la dernière heure embrumée de l’après-midi à une relecture à haut risque.

Les heures, c’est ce que vous avez. L’énergie, c’est ce que vous dépensez.

Les agents facilitent cet accord, puisque tant de travail routinier peut désormais être délégué. Mais ils créent aussi une nouvelle fuite d’énergie : la demande constante et diffuse de surveiller les fils, de lire les comptes rendus et de répondre aux notifications. Chaque demande est petite. Ensemble, elles peuvent consommer une part étonnante de votre meilleure énergie si vous les laissez entrer dans vos meilleures heures. Protégez ces heures. Regroupez la surveillance dans les parties les moins précieuses de la journée.

L’énergie a aussi une forme hebdomadaire et saisonnière. Beaucoup d’opérateurs constatent qu’ils décident mieux en début de semaine et relisent mieux en milieu de semaine, ou que certains mois sont régulièrement plus éprouvants que d’autres. Repérez vos propres motifs et planifiez en conséquence. Placez les grosses décisions là où vous êtes le plus fort. Allégez la charge là où vous savez que vous serez plus faible.

Il est tentant de traiter l’énergie comme une affaire de volonté, de traverser en force les périodes de faible énergie. Cela marche à l’occasion et échoue comme stratégie. Les décisions prises avec peu d’énergie sont moins bonnes, les relectures faites avec peu d’énergie ratent des choses, et le coût de ces ratés arrive plus tard et plus lourd. Mieux vaut faire moins, et bien, que plus, et mal, surtout quand les agents sont tout à fait disposés à continuer de faire sans vous.

Cette semaine, notez votre énergie chaque heure sur une échelle simple : haute, moyenne ou basse. En fin de semaine, regardez le motif et repérez vos meilleures heures. Puis déplacez-y vos décisions et relectures les plus importantes, et mettez la routine dans le reste. C’est un petit réaménagement. Son effet sur la qualité de votre travail n’a rien de petit.

L’attention a un plafond

Avec des agents, le nombre de choses que vous pourriez faire tourner en même temps est pratiquement illimité. Dix fils, vingt, cinquante, chacun travaillant sur quelque chose d’utile. La contrainte n’est pas les agents mais vous, car chaque fil finit par avoir besoin de votre attention : pour le briefer, le débloquer, relire sa production et décider de la suite. Votre attention a un plafond, et ce plafond est bien plus bas que le nombre de fils que vous pourriez lancer.

Imaginez trois nombres. Les fils que vous pourriez lancer : un très grand nombre, limité seulement par les idées et le budget. Les fils que vous pouvez surveiller, en suivant leur progression et en les rattrapant quand ils dérivent : bien moins, peut-être une poignée à la fois. Les fils que vous pouvez relire correctement, en accordant à leur production l’attention soigneuse qu’elle exige avant livraison : moins encore. Ce dernier nombre est la capacité réelle de l’activité. Tout ce qui le dépasse produit de la matière qui soit attendra dans une file, soit sera livrée insuffisamment relue.

La plupart des opérateurs, quand ils découvrent les agents, tournent bien au-dessus du plafond. Cela paraît efficace : plus de fils, plus de production, plus de progrès. En pratique, cela produit un arriéré de travail non relu, un sentiment croissant d’être en retard et un abaissement insidieux des exigences de relecture à mesure qu’on essaie de suivre. Le travail ne se fait pas plus vite. Il se fait moins bien, et une partie doit ensuite être refaite.

Lancez autant de fils que vous pouvez en relire. Pas un de plus.

Trouver votre plafond demande une observation honnête. Pendant une semaine, notez combien de fils vous lancez chaque jour et combien de leurs productions vous relisez correctement plutôt que de les survoler. Le point où le survol commence est à peu près votre plafond. Pour beaucoup d’opérateurs, il se situe entre trois et six fils conséquents par jour, même s’il varie beaucoup selon la nature du travail et la qualité des briefs.

De meilleurs briefs relèvent le plafond. Un fil doté d’une définition claire de « fini » et d’exigences de preuve solides se relit plus vite qu’un fil qui n’en a pas, si bien que vous pouvez en relire davantage. Les petites modifications le relèvent aussi, car chacune demande moins de relecture. Les bonnes recettes le relèvent, car le travail familier s’évalue plus vite. Ce sont autant de façons de tirer davantage de la même attention, et elles sont bien plus efficaces que de simplement faire plus d’efforts.

Déléguer la relecture le relève un peu, mais seulement un peu. Un agent relecteur peut faire une première passe sur la production, signaler les problèmes et résumer les modifications, et cela fait gagner du temps. Cela ne supprime pas le besoin de votre relecture, car c’est par elle que votre jugement et votre responsabilité entrent dans le travail. Voyez l’agent relecteur comme un assistant qui prépare les dossiers, pas comme un assistant qui les signe.

Quand vous êtes au-dessus du plafond, le remède n’est pas de travailler plus longtemps mais de lancer moins de fils. Mettez des projets en sommeil. Enchaînez un travail qui était parallèle. Laissez certaines idées attendre dans la file. On a l’impression de ralentir. C’est en réalité accélérer, car un travail correctement relu n’est livré qu’une fois, et non deux.

Cette semaine, trouvez votre plafond. Puis, la semaine suivante, ne lancez pas plus de fils qu’il n’en permet. Observez si l’on livre davantage ou moins. La plupart des opérateurs sont surpris de la réponse, et agréablement.

Les heures où vous êtes bon

Personne n’est capable de huit heures d’affilée de jugement de haute qualité. La plupart des gens en sont capables pendant quelques heures, éparpillées dans la journée selon un motif étonnamment constant une fois qu’on l’a remarqué. Un opérateur qui organise sa journée autour de ces heures en tire davantage que celui qui traite toutes les heures comme interchangeables, et bien davantage que celui qui les dépense aux mauvaises choses.

La journée alterne naturellement entre trois sortes de temps. Le travail profond : les heures où vous pouvez vous concentrer pleinement, prendre des décisions difficiles et relire avec soin des modifications complexes. Le travail léger : les heures où vous pouvez faire des choses utiles qui ne demandent pas une pleine concentration, comme ranger, faire des relectures de routine, fermer des fils, écrire des briefs simples. Et la récupération : le temps entre les deux, quand vous ne travaillez pas du tout et que votre capacité pour la prochaine plage profonde se reconstitue. Les trois sont nécessaires. L’erreur est de traiter le travail léger ou la récupération comme des échecs à faire du travail profond.

Pour la plupart des gens, le travail profond vient par blocs d’une heure ou deux, quelques fois par jour au maximum. Certains trouvent leur meilleur bloc tôt le matin ; d’autres en fin de matinée ; quelques-uns le soir. Le motif est personnel, mais il est généralement stable, et il vaut la peine de l’apprendre. Une fois que vous connaissez vos heures profondes, protégez-les. Pas de messages, pas de surveillance, pas de travail léger qui peut attendre. Placez-y la partie la plus exigeante des trois résultats du jour.

On ne peut pas travailler en profondeur toute la journée. On peut organiser la journée pour que les heures profondes fassent le travail profond.

Le travail léger remplit une bonne partie du reste, et les agents en ont changé la nature. Une bonne part de ce qui était autrefois du travail léger, mise en forme, recherche, rédaction de routine, est désormais déléguée. Ce qui reste est surtout de la surveillance et de la relecture rapide : consulter les fils, approuver des modifications simples, lire des condensés. C’est du vrai travail et il doit être planifié, pas autorisé à s’infiltrer dans les heures profondes où il fait le plus de dégâts.

La récupération est la partie que les gens sautent, et celle qui détermine si le bloc profond suivant vaudra quelque chose. Une marche, un repas, une conversation, une heure à faire quelque chose sans rapport. Consulter les fils sur son téléphone pendant une pause n’est pas de la récupération ; c’est du travail léger sur une autre chaise. Les agents se passeront très bien de vous pendant une heure. Vous vous porterez mieux d’avoir été ailleurs.

Le cycle se répète au fil de la journée. Profond, léger, récupération, puis profond de nouveau si vous avez encore un bloc en vous, léger, récupération, clôture. Beaucoup d’opérateurs constatent que deux blocs profonds font une bonne journée et que trois relèvent de l’exceptionnel. Planifier davantage tend à produire des blocs profonds sur le papier et superficiels en réalité.

Cette semaine, repérez les heures où vous pensez le mieux. Puis organisez la semaine suivante autour d’elles : les décisions et relectures les plus difficiles dans les blocs profonds, la routine dans les blocs légers, et de vraies pauses entre les deux. Traitez les pauses comme des rendez-vous, pas comme des restes. En fin de semaine, comparez la qualité de vos relectures et de vos décisions à celle de la semaine précédente. Les heures étaient les mêmes. Ce que vous y avez mis, non.

Le repos est de l’entretien

Il existe un présupposé discret, répandu chez ceux qui travaillent seuls et plus encore chez ceux qui disposent d’agents infatigables : le repos serait ce qu’on mérite une fois le travail terminé. Le travail n’est jamais terminé, alors le repos n’arrive jamais tout à fait. Les agents continuent de tourner, les fils continuent de se terminer, il y a toujours une chose de plus à relire, et les soirées et les week-ends se remplissent peu à peu de petits gestes de vérification. Cela ressemble à de la diligence. C’est la lente défaillance de la pièce la plus importante de la machine.

Le repos n’est pas une récompense. C’est de l’entretien. Le jugement de l’opérateur, ce qui fait fonctionner toutes les autres pièces, dépend du repos comme une machine dépend de l’huile. Sans lui, les décisions se dégradent, les relectures ratent des choses, les briefs deviennent plus vagues, et le coût de ces défaillances apparaît plus tard, sous forme de reprises, d’incidents et de cette fatigue particulière qu’on éprouve à réparer des problèmes causés quand on était épuisé. Le bon jugement vit à l’intersection du travail et du repos. Retirez le repos, et l’intersection disparaît.

Les agents compliquent les choses d’une façon particulière : ils n’ont jamais besoin de repos, donc ils ne vous offrent jamais de point d’arrêt naturel. Une équipe humaine rentre chez elle en fin de journée, et le travail s’interrompt. Les agents peuvent tourner toute la nuit, et savoir que quelque chose a peut-être fini crée une attraction vers la vérification. Cette attraction est la plus forte précisément quand il faut le plus y résister, tard le soir et le week-end, quand votre jugement est au plus bas et que le coût d’agir sur une chose à moitié lue est au plus haut.

La machine peut tourner sans repos. L’opérateur, non. Planifiez en conséquence.

Intégrez donc le repos à la structure, pas aux restes. La clôture quotidienne termine explicitement la journée de travail. Le week-end est un week-end : pas de relectures, pas de briefs, pas de vérifications, sauf si quelque chose brûle vraiment, et presque rien ne brûle. Les vacances sont des vacances, préparées à l’avance avec des projets mis en sommeil et des passations claires, pour que rien n’ait besoin de vous pendant votre absence. Ces frontières ne sont pas des luxes. Elles font partie du système d’exploitation.

Rendez les frontières plus faciles à tenir en concevant pour elles. Le travail d’agents la nuit et le week-end doit se limiter à des tâches bien briefées, à faible risque, qui peuvent sans danger attendre d’être relues. Les notifications doivent être coupées en dehors des heures de travail. Tout ce qui pourrait réellement avoir besoin de vous en urgence doit être rare, bien défini et acheminé par un canal unique, pour que le silence de ce canal signifie que vous pouvez vraiment vous arrêter.

Il est utile de distinguer le repos de la distraction. Faire défiler un écran, regarder quelque chose d’un œil en pensant au travail ou faire un peu d’administratif le dimanche, ce n’est pas du repos. Le repos est un temps pendant lequel le travail n’est vraiment pas dans votre tête : le sport, les gens, le sommeil, des activités absorbantes qui n’ont rien à voir avec l’activité. C’est là que l’esprit accomplit son lent travail de fond pour donner sens aux choses, et beaucoup des meilleures décisions arrivent, sans y être invitées, le lundi qui suit un vrai week-end.

Cette semaine, fixez une frontière ferme : une soirée et une journée entière sans vérification, sans brief, sans relecture. Préparez-la à la clôture qui précède. Observez ce qui arrive à votre première relecture ensuite. La plupart des opérateurs la trouvent nettement plus affûtée. Cet affûtage, c’est l’entretien qui porte ses fruits.

Un rythme qu’on peut tenir

Les opérateurs les plus productifs ne sont pas ceux qui ont les semaines les plus impressionnantes. Ce sont ceux qui ont de bonnes semaines, régulièrement, pendant des années. Un rythme qu’on peut tenir vaut mieux qu’un rythme qui impressionne, parce que l’activité capitalise. Les recettes s’améliorent, la mémoire s’approfondit, le registre reste sain, le jugement s’affûte, et le travail de chaque année se bâtit sur les fondations de l’année précédente. Les coups de collier héroïques suivis de récupération ne capitalisent pas. Ils oscillent.

Les agents poussent les opérateurs vers les coups de collier. La capacité est là : vous pourriez lancer vingt fils, travailler toute la nuit et livrer un produit entier en un week-end. C’est parfois le bon choix, pour une vraie échéance ou une occasion qui n’attendra pas. Comme habitude, c’est corrosif. Chaque coup de collier emprunte à l’énergie et au jugement des semaines suivantes, et l’emprunt se rembourse avec intérêts sous forme de décisions fatiguées, de relectures manquées et de la lente accumulation de problèmes qu’on a laissés passer dans la précipitation.

Un rythme soutenable commence par une journée régulière : la revue, les sessions et la clôture décrites plus haut, avec les trois du jour comme cible et le plafond d’attention respecté. Les journées régulières font une semaine régulière, avec sa revue, sa place nette et son décompte honnête de ce qui a été livré. Les semaines régulières font une année régulière, avec des revues trimestrielles qui changent de cap délibérément et une activité nettement meilleure à la fin qu’au début. La chaîne n’a rien de remarquable à aucun de ses maillons. Le résultat au bout l’est.

Les exploits font de bonnes histoires. Les habitudes font de bonnes années.

À quoi ressemble un rythme soutenable vu de l’intérieur ? Surtout au calme. Vous savez sur quoi vous travaillez et pourquoi. Vous savez ce qui a été livré la semaine dernière. Vous n’êtes pas en retard dans vos relectures, parce que vous ne lancez que ce que vous pouvez relire. Vous vous arrêtez en fin de journée sans angoisse, parce que la clôture a tout recueilli. Vous prenez vos week-ends et vos vacances sans appréhension, parce que l’activité est conçue pour faire une pause.

C’est généralement le cas. Le test n’est pas l’impression de difficulté, mais ce que cela produit sur des mois. Un opérateur serein qui livre trois choses bien relues par jour, tous les jours, produit davantage qu’un opérateur frénétique qui livre dix choses une semaine et rien la suivante, le temps de se remettre de la première. Et le travail de l’opérateur serein tend à être meilleur, parce qu’il a été relu par quelqu’un qui faisait attention.

Le rythme est aussi quelque chose qu’on peut ajuster délibérément. Il y a des saisons où pousser un peu plus est juste, et des saisons où lever un peu le pied est sage. La revue trimestrielle est l’endroit naturel pour en décider : de quel rythme le trimestre qui vient a-t-il besoin, et que ferai-je pour qu’il soit soutenable ? Décider du rythme délibérément est très différent de le voir décidé pour vous par ce qui crie le plus fort.

Cette semaine, demandez-vous honnêtement : pourrais-je tenir le rythme de cette semaine pendant un an ? Si la réponse est non, trouvez la chose qui le rend insoutenable et changez-la. Puis reposez la question la semaine suivante. Le but est un oui auquel vous croyez. Quand vous y serez, vous aurez la chose la plus précieuse qu’un opérateur puisse construire : une machine qui tourne bien, indéfiniment, avec vous toujours dans le fauteuil.

Moins d’outils, mieux entretenus

Il n’y a jamais eu de meilleure époque pour collectionner les outils. De nouveaux produits d’agents, extensions, connecteurs, plug-ins et services arrivent chaque semaine, chacun promettant d’éliminer une friction de votre journée. Beaucoup sont réellement bons. La plupart des opérateurs en essaient énormément et en gardent plus qu’ils n’en utilisent. Le résultat est une ceinture à outils si lourde qu’elle les ralentit : trop d’endroits où regarder, trop d’abonnements à gérer, trop d’intégrations susceptibles de casser, et trop peu de connaissance approfondie de chacun.

La meilleure approche : moins d’outils, mieux entretenus. Un petit ensemble que vous connaissez à fond, utilisez chaque jour et entretenez correctement vous servira mieux qu’un grand ensemble que vous connaissez superficiellement et utilisez de temps en temps. La profondeur compte, parce que la valeur d’un outil vient surtout du fait de bien le connaître : ses raccourcis, ses limites, ses modes de défaillance, son comportement quand quelque chose tourne mal. Ce savoir prend du temps à se constituer, et il s’éparpille quand la ceinture est large.

Voyez cela comme un entonnoir. En haut, tous les outils que vous avez jamais essayés. En dessous, ceux que vous utilisez réellement chaque semaine. Tout en bas, votre ceinture à outils : le petit ensemble sur lequel vous comptez, que vous connaissez vraiment et dont vous remarqueriez immédiatement la panne. Si la vôtre en compte trente, la plupart se trouvent probablement en haut de l’entonnoir en se faisant passer pour le bas.

Un outil que vous connaissez bien vaut mieux que deux que vous connaissez à moitié.

Chaque outil a un coût de possession, même s’il est gratuit. Il faut le mettre à jour. Il faut revoir ses autorisations. Il faut surveiller ses intégrations. Il occupe de la place dans votre esprit et dans vos fichiers de mémoire. Quand il change, il faut apprendre le changement. Quand il tombe en panne, il faut le remarquer et réagir. Pour un outil utilisé chaque jour, ce coût se justifie aisément. Pour un outil utilisé une fois par mois, souvent pas.

Soyez donc lent à adopter et prompt à abandonner. Quand un nouvel outil apparaît, demandez-vous quel problème précis il résoudrait que vos outils actuels ne résolvent pas. Si vous ne pouvez pas en nommer un, laissez-le passer, aussi impressionnant soit-il. Si vous le pouvez, essayez-le sur un travail petit et circonscrit avant de le laisser entrer dans votre rythme quotidien. Et quand un outil cesse de mériter sa place, retirez-le proprement, y compris ses autorisations et toute mémoire ou recette qui y fait référence.

Ce principe s’accorde bien avec la règle de la petite machine de la première partie de ce livre. Une petite ceinture à outils fait partie d’une petite machine, et une petite machine est une machine qu’on peut tenir dans sa tête un mauvais jour. Quand quelque chose tourne mal dans une activité à cinq outils, vous savez où regarder. Quand quelque chose tourne mal dans une activité à trente outils, vous risquez de passer la matinée à découvrir lequel est en cause.

Cette semaine, listez chaque outil, service et intégration qu’utilise actuellement votre activité. Indiquez pour chacun la fréquence à laquelle vous l’avez utilisé le mois dernier. Tout ce que vous n’avez pas utilisé est candidat au retrait. Tout ce que vous n’avez utilisé qu’une ou deux fois mérite un examen sévère. Puis retirez au moins un outil, proprement. Votre ceinture sera plus légère, et l’espace libéré vous permettra de connaître un peu mieux le reste.

L’audit de la ceinture à outils

Les outils s’accumulent en silence. Un connecteur ajouté pour un projet reste branché après la fin du projet. Une extension de navigateur installée pour un essai tourne encore des mois plus tard. Un abonnement se renouvelle parce que personne ne l’a regardé. Une intégration d’agent a toujours accès à un dossier que vous n’utilisez plus. Rien de tout cela n’est spectaculaire. Tout cela est du fouillis, une partie coûte de l’argent, et une petite partie constitue un risque de sécurité. Le remède est un audit régulier.

L’audit de la ceinture à outils est une revue courte et structurée, une fois par trimestre, de tout ce qui, dans votre activité, est un outil : logiciels, services, abonnements, connecteurs, intégrations, extensions, scripts et automatisations. Il compte trois étapes. Tout lister. Vérifier l’usage de chacun. Décider quoi garder, modifier ou retirer.

Lister est l’étape la plus révélatrice. La plupart des opérateurs, la première fois, découvrent des outils dont ils avaient oublié l’existence. Regardez partout : applications installées, extensions de navigateur, services connectés à chacune de vos principales plateformes, connecteurs d’agents et leurs autorisations, tâches planifiées, automatisations, abonnements sur vos relevés. Les agents peuvent aider pour une partie, notamment pour lister les intégrations et les tâches planifiées, mais il vous faudra regarder certains endroits vous-même.

Chaque outil que vous aviez oublié est un outil qui peut vous surprendre.

Vérifier l’usage, c’est se demander pour chaque élément : quand m’en suis-je servi pour la dernière fois, pour quoi faire, et remarquerais-je sa disparition ? Demandez-vous aussi à quoi il a accès. Un outil rarement utilisé qui dispose d’un large accès à vos fichiers ou comptes est bien plus préoccupant qu’un outil utilisé chaque jour avec un accès restreint. Prêtez une attention particulière à tout ce qui est connecté aux agents, car les agents agissent selon les accès qu’on leur donne, et un accès périmé est une invitation à ce que quelque chose tourne mal d’une façon que vous n’aurez pas anticipée.

Décider est le but de l’exercice. Gardez les outils que vous utilisez et qui vous manqueraient. Modifiez ceux que vous utilisez mais avez mal configurés : trop d’accès, réglages dépassés, chevauchement avec un autre outil. Retirez proprement ceux que vous n’utilisez pas : révoquez leurs accès, résiliez les abonnements, supprimez les intégrations, et mettez à jour les fichiers de mémoire ou recettes qui les mentionnent. Retirer un outil de sa vie en laissant ses accès en place n’est pas un retrait. C’est un abandon.

L’audit est aussi un bon moment pour vérifier la santé des outils que vous gardez. Sont-ils à jour ? Leurs réglages sont-ils ceux que vous croyez ? Ont-ils changé d’une façon qui affecte votre usage ? Y a-t-il quelque chose à leur sujet que vous comptiez apprendre ? Un peu d’attention ici garde la ceinture affûtée plutôt que simplement présente.

Consignez brièvement l’audit dans le carnet ou le journal des décisions : ce que vous avez retiré, ce que vous avez modifié, ce qui vous a surpris. Le trimestre suivant, commencez par relire le dernier audit. Avec le temps, ces traces vous montrent comment évolue votre ceinture à outils, si elle grossit ou s’allège, ce qui est un bon indicateur du respect de la règle de la petite machine.

Ce trimestre, menez l’audit. Lister, vérifier, décider. Visez à retirer au moins quelques éléments et à restreindre les accès d’au moins un. Cela prend un après-midi. Vous en ressortez avec une activité que vous comprenez mieux, et qui offre moins d’endroits où quelque chose d’inattendu peut se produire.

L’entretien se planifie

Toute activité demande de l’entretien. Les outils doivent être mis à jour. Les dépendances doivent être montées de version. Les fichiers de mémoire doivent être élagués. Les recettes doivent être rafraîchies. Les identifiants doivent être changés. Les sauvegardes doivent être testées. Les noms de domaine, certificats et abonnements doivent être renouvelés. Rien de tout cela n’est intéressant, rien n’est urgent jusqu’au moment où cela le devient soudain, et tout est facile à remettre à plus tard. La seule façon fiable de s’en acquitter est de le planifier.

L’entretien non planifié se fait de deux façons : jamais, ou en pleine crise. Le certificat expire et le site tombe. La dépendance a trois versions majeures de retard et la mise à jour représente désormais une semaine de travail au lieu d’une heure. L’identifiant qui aurait dû être changé est exposé. La sauvegarde jamais testée se révèle impossible à restaurer. Chaque crise coûte bien plus que l’entretien planifié n’aurait coûté, et chacune arrive au moment choisi par le problème, pas par vous.

L’entretien planifié transforme ces crises en routine. Le cycle est simple. Planifiez chaque tâche d’entretien à un intervalle raisonnable. Quand elle revient, faites la mise à jour. Puis vérifiez que la mise à jour a fonctionné et que rien n’a cassé. L’occurrence suivante est alors déjà au calendrier. Le point de départ du cycle, la planification, concentre l’essentiel de la valeur, car c’est elle qui fait que le reste a lieu.

L’entretien inscrit à l’agenda coûte peu. L’entretien en urgence, non.

Établissez un calendrier d’entretien. Certaines tâches sont hebdomadaires : vérifier que les tâches automatiques ont tourné, jeter un œil aux journaux d’erreurs. Certaines sont mensuelles : mettre à jour les dépendances, élaguer les fichiers de mémoire, passer en revue les fils ouverts. Certaines sont trimestrielles : l’audit de la ceinture à outils, le changement des identifiants, un test de restauration de sauvegarde, la revue des recettes. Certaines sont annuelles : renouveler les noms de domaine, revoir chaque abonnement. Notez-les avec leurs intervalles et mettez-les dans l’agenda que vous regardez réellement.

Les agents excellent dans le travail d’entretien, et c’est l’un des meilleurs endroits où les employer. Une recette de mise à jour des dépendances peut demander à un agent de monter de version, de lancer la suite de tests complète et de signaler tout échec. Une recette d’élagage de la mémoire peut demander à un agent de signaler les entrées périmées. Une recette de vérification des sauvegardes peut dérouler une restauration vers un emplacement de test. Des tâches d’agents planifiées peuvent exécuter certaines de ces recettes automatiquement. Il vous faut toujours relire les résultats, mais la relecture est rapide quand le travail est routinier et la recette bonne.

L’étape de vérification mérite qu’on insiste. Un entretien fait mais non vérifié est à moitié fait. Une mise à jour qui a cassé quelque chose en silence, un changement d’identifiant qui a laissé l’ancien actif, une sauvegarde qui tourne mais produit des fichiers vides : chacun paraît accompli jusqu’au moment où l’on en a besoin. Chaque tâche d’entretien doit se terminer par une vérification qu’elle a réellement atteint son but.

Gardez le calendrier d’entretien court et réaliste. S’il liste cinquante tâches, beaucoup seront sautées, et l’habitude s’érodera. Commencez par la poignée de tâches dont l’échec ferait le plus mal, planifiez-les, et n’en ajoutez d’autres qu’une fois l’habitude bien installée. Une courte liste tenue de façon fiable vaut mieux qu’une longue liste tenue de temps en temps.

Cette semaine, écrivez votre calendrier d’entretien. Listez les tâches, fixez leurs intervalles, et inscrivez la prochaine occurrence de chacune dans votre agenda. Puis faites aujourd’hui une tâche en retard. Ce petit geste de rattrapage est le début d’une vie où l’on n’a plus jamais à rattraper.

Les autorisations comme politique

Les agents agissent selon les autorisations qu’on leur donne. La plupart des outils d’agents offrent désormais toute une gamme de modes, de la demande d’accord avant chaque action à la liberté d’agir dans certaines limites, ainsi que des moyens d’autoriser ou d’interdire des commandes, fichiers et services précis. Beaucoup d’opérateurs gèrent les autorisations de façon réactive : ils approuvent les demandes une à une à mesure qu’elles surgissent, et en autorisent progressivement davantage à mesure que les sollicitations les lassent. Le résultat est un ensemble d’autorisations que personne n’a réellement conçu, et qui peut permettre bien plus, ou bien moins, que prévu.

Une meilleure approche consiste à traiter les autorisations comme une politique. Décidez une fois, délibérément, ce que les agents peuvent faire sans demander, ce sur quoi ils doivent d’abord demander, et ce qu’ils ne doivent jamais faire. Écrivez cette politique. Configurez vos outils pour l’appliquer. Vous pourrez alors cesser de prendre les mêmes petites décisions des dizaines de fois par jour, et faire confiance au fait que les limites reflètent votre jugement réfléchi plutôt que votre niveau d’agacement à seize heures.

La politique compte trois niveaux. Autorisé sans demander : les actions sûres, réversibles et routinières, comme lire les fichiers du projet, lancer la suite de tests, modifier des fichiers dans le périmètre du projet. Demander avant d’agir : les actions importantes ou plus difficiles à annuler, comme installer des dépendances, modifier la configuration, lancer des commandes aux effets de bord hors du projet, faire des appels réseau vers des destinations inconnues. Jamais autorisé : les actions destructrices, irréversibles ou hors des limites de l’activité, comme supprimer hors du projet, toucher aux identifiants, pousser directement en production, accéder à des fichiers personnels.

Décidez vos autorisations une fois, au calme, pour ne pas avoir à les décider cent fois dans le feu de l’action.

Des projets différents peuvent demander des politiques différentes. Une expérience jetable peut être généreuse. Un projet client aux données sensibles doit être strict. Un système en production doit l’être plus encore. Beaucoup d’outils permettent de régler les autorisations par projet, ce qui est exactement ce qu’il faut : la politique épouse le risque.

Revoyez la politique lors de l’audit de la ceinture à outils, ou quand quelque chose tourne mal. Regardez ce que vous avez autorisé et demandez-vous si chaque élément est encore approprié. Regardez ce que les agents demandent sans cesse et demandez-vous si ces demandes devraient être pré-approuvées ou rester des sollicitations. Regardez les incidents et demandez-vous si un changement d’autorisation les aurait évités. Les autorisations jamais revues ont tendance à dériver vers trop de générosité, car chaque approbation prise isolément semble inoffensive.

Prêtez une attention particulière aux autorisations du travail sans surveillance : tâches de nuit, tâches planifiées, tout ce qui tourne sans que vous regardiez. Celles-ci doivent être les plus restrictives de toutes, car personne n’est là pour attraper une erreur au moment où elle se produit. Une bonne règle : les agents sans surveillance ne reçoivent que ce dont la tâche précise a besoin, et rien de plus.

Une bonne politique a un effet secondaire agréable : moins d’interruptions. Quand les actions routinières sont pré-approuvées et les dangereuses bloquées, les seules sollicitations que vous voyez concernent des actions réellement importantes, et ce sont celles qui méritent votre attention. Le flot des demandes d’approbation triviales disparaît, et avec lui l’habitude de cliquer sur oui sans lire.

Cette semaine, écrivez la politique d’autorisations de votre projet principal : trois courtes listes. Puis comparez la configuration réelle de votre outil à cette politique et corrigez tout écart. Remarquez combien de sollicitations disparaissent, et combien vous êtes plus attentif à celles qui restent.

Les victoires fragiles coûtent plus cher

Parfois, le moyen le plus rapide de faire fonctionner quelque chose est une bidouille. Une valeur codée en dur. Une étape manuelle dont quelqu’un doit se souvenir. Un script qui marche sur votre machine et nulle part ailleurs. Un contournement d’agent qui fait taire une erreur au lieu de la corriger. La bidouille vous offre une victoire aujourd’hui, et les victoires font du bien. Mais les victoires fragiles portent intérêt, et l’intérêt se paie plus tard, généralement au pire moment et généralement plus cher que ce que valait la victoire d’origine.

Le problème des victoires fragiles n’est pas qu’elles échouent. Tout finit par échouer. C’est qu’elles échouent de façon imprévisible et silencieuse. Une date codée en dur fonctionne jusqu’à ce que la date soit passée. Une étape manuelle fonctionne jusqu’à ce que vous l’oubliiez. Une erreur étouffée cache un problème jusqu’à ce que le problème devienne assez gros pour percer. Quand elles échouent, souvent vous ignoriez qu’elles étaient fragiles, parce que la bidouille a été faite il y a des mois, peut-être par un agent, et que personne ne l’a notée.

Pensez les solutions selon deux axes : la rapidité avec laquelle elles livrent un résultat maintenant, et leur fragilité. Une solution rapide et fragile est tentante et dangereuse. Une solution lente et robuste est sûre et parfois disproportionnée. Le coin que vous voulez généralement est « assez rapide et assez robuste » : pas la correction la plus rapide possible, ni la plus blindée, mais une qui continuera de fonctionner sans que personne se souvienne qu’elle existe.

La bidouille fait gagner une heure aujourd’hui et coûte une journée le pire jour du mois.

Les agents peuvent produire des victoires fragiles très vite, surtout quand on leur demande de faire marcher quelque chose sous pression. Un agent à qui l’on dit fais passer les tests trouvera peut-être le chemin le plus rapide, qui n’est pas toujours le bon. Guettez les signes à la relecture : des valeurs codées en dur qui devraient relever de la configuration, des erreurs attrapées et ignorées, des cas particuliers ajoutés pour une seule entrée, des commentaires disant temporaire ou à corriger plus tard. Chacun est une victoire fragile en germe.

Quand vous acceptez une victoire fragile, et il le faut parfois, parce qu’une échéance est réelle ou que l’enjeu est faible, consignez-la. Écrivez une ligne dans le journal des décisions ou la mémoire du projet : ce qu’est la bidouille, pourquoi elle a été acceptée, et ce que serait la vraie correction. Ajoutez un rappel pour y revenir. Une bidouille consignée est une dette connue assortie d’un plan de remboursement. Une bidouille non consignée est un piège qui attend quelqu’un, généralement vous.

Une partie de la fragilité vient de l’activité elle-même plutôt que du travail : une étape que vous seul savez faire, un processus qui dépend de votre mémoire, une intégration que personne d’autre ne saurait réparer. Ce sont des victoires fragiles à l’échelle de la machine, et elles comptent plus encore pour un opérateur solitaire, puisqu’il n’y a aucun collègue sur qui se rabattre. Les chapitres suivants, sur les incidents et les runbooks, traitent largement de la façon de transformer ce genre de fragilité en quelque chose de plus solide.

Cette semaine, cherchez les victoires fragiles dans un projet. Traquez les valeurs codées en dur, les erreurs étouffées, les commentaires « temporaire » et les étapes manuelles non documentées. Consignez chacune de celles que vous trouvez, et corrigez celle qui a le plus de chances de causer des ennuis. Ce n’est pas un travail palpitant. C’est le genre de travail qui rend le mois suivant sans histoire, et c’est la meilleure sorte de mois qui soit.

Les erreurs sont des données

Les erreurs sont inévitables dans toute activité, et une activité équipée d’agents en produit une variété particulière. Un brief mal lu. Une modification qui a cassé quelque chose d’inattendu. Une relecture qui a raté un problème. Une livraison partie au mauvais endroit. Un message envoyé avec une erreur dedans. Chacune est agaçante et parfois coûteuse. Chacune est aussi une donnée, et l’opérateur qui traite les erreurs comme des données progresse bien plus vite que celui qui les traite comme des embarras à corriger puis oublier.

Quand une erreur se produit, le chemin bifurque. L’une des voies mène à la dissimulation ou à l’oubli : corriger discrètement, passer à autre chose, espérer que cela ne se reproduise pas. C’est la voie naturelle, car les erreurs sont inconfortables et les corriger satisfaisant. L’autre voie mène à l’apprentissage : corriger, puis se demander pourquoi c’est arrivé et ce qui l’empêcherait la prochaine fois. La seconde voie prend quelques minutes de plus. C’est la seule qui améliore l’activité.

La valeur se trouve dans le pourquoi. La plupart des erreurs ont des causes situées en amont de l’erreur visible. L’agent a mal lu le brief parce que le brief était ambigu. La modification a cassé quelque chose parce qu’aucun test ne couvrait ce chemin. La relecture a raté le problème parce qu’elle a eu lieu à la fin d’une longue journée. La livraison est partie au mauvais endroit parce que le processus de déploiement comporte une étape déroutante. Ne corrigez que l’erreur visible, et la cause en amont demeure, prête à produire l’erreur suivante.

Une erreur corrigée, c’est un problème résolu. Une erreur comprise, c’est une classe de problèmes résolue.

Recueillez les erreurs quelque part. Une section du carnet, un simple journal, ou des notes d’incident pour les plus importantes, dont traite le chapitre suivant. Avec le temps, la collection révèle des motifs : le même genre de brief est sans cesse mal lu, la même zone de code casse sans cesse, la même heure de la journée produit sans cesse des erreurs. Les motifs sont bien plus utiles que les erreurs isolées, car ils désignent des corrections systémiques qui préviennent d’un coup de nombreuses erreurs futures.

Les agents se trompent aussi, et ils méritent le même traitement. Quand un agent fait quelque chose de travers, résistez à l’envie d’accuser l’agent et de passer à autre chose. Demandez-vous ce qui, dans le brief, la mémoire, les autorisations ou les vérifications, a permis que cela arrive. Il y a généralement quelque chose, et le corriger améliore toutes les exécutions futures. L’erreur d’un agent, c’est souvent votre système qui vous indique où il est incomplet.

Vos propres erreurs méritent la même curiosité, et ici un peu d’indulgence envers soi-même aide. Les opérateurs durs avec eux-mêmes ont tendance à cacher leurs erreurs, même à leur propre carnet, parce que les écrire donne l’impression de ressasser l’échec. Mais le carnet n’est pas un bulletin de notes. C’est un outil pour s’améliorer. Une erreur notée calmement et examinée est un cadeau fait à votre futur vous. Une erreur enterrée n’est un cadeau pour personne.

Cette semaine, chaque fois que quelque chose tourne mal, aussi petit soit-il, écrivez une ligne : ce qui s’est passé et pourquoi vous pensez que c’est arrivé. N’essayez pas encore d’en corriger les causes. Recueillez, simplement. À la revue hebdomadaire, lisez les lignes et cherchez un motif. Si vous en trouvez un, corrigez sa cause. Vous aurez transformé une semaine d’agacements en une amélioration durable, ce qui est un excellent échange.

La note d’incident

Quand quelque chose d’important tourne mal, une livraison qui a cassé une fonctionnalité, des données perdues, une erreur qui a atteint un client, une action d’agent qui n’aurait pas dû se produire, écrivez une note d’incident. Pas un long rapport, pas un post-mortem en bonne et due forme, juste une note courte et structurée qui consigne ce qui s’est passé, pourquoi, et ce qui va changer. Cela prend un quart d’heure. C’est le moyen le plus efficace dont dispose un opérateur pour s’assurer que la même chose n’arrive pas deux fois.

La note répond à trois questions, dans l’ordre. Ce qui s’est passé : un récit factuel, avec les heures si elles comptent. Quel a été l’effet, qui l’a remarqué, comment cela a-t-il été résolu ? Gardez cette partie simple et précise. Pourquoi c’est arrivé : les causes, l’immédiate comme celles d’amont. La cause immédiate pourrait être la migration a supprimé les lignes aux noms vides. Les causes d’amont pourraient être le brief ne mentionnait pas les noms vides, aucun test ne couvrait ce cas, et la modification a été fusionnée automatiquement parce qu’elle était étiquetée à faible risque. Ce qui change : les actions précises que vous mènerez pour empêcher que cela se reproduise. Chaque action doit être concrète et assortie d’une échéance, même si la seule personne à qui l’attribuer est vous.

La question du milieu est celle qui a de la valeur, et elle mérite l’essentiel du quart d’heure. Une technique utile consiste à continuer de demander pourquoi jusqu’à atteindre quelque chose que vous pouvez changer dans le système plutôt que dans l’instant. L’agent a supprimé les lignes : pourquoi ? Parce que le brief ne disait pas de ne pas le faire : pourquoi ? Parce que j’ignorais l’existence de noms vides : pourquoi ? Parce que les données n’ont jamais été profilées : voilà quelque chose que vous pouvez corriger.

Un incident sans note est un incident que vous avez accepté de revivre.

La section « ce qui change » doit compter un petit nombre d’actions réelles, pas une longue liste de bonnes intentions. Ajouter un test. Mettre à jour la recette. Modifier les conditions de fusion automatique. Ajouter une ligne à la mémoire du projet. Profiler les données. Chacune doit être faite en quelques jours, pas en quelques semaines, et la note mise à jour quand c’est fait. Une note d’incident dont les actions ne sont jamais accomplies est la trace d’une leçon non apprise.

Rangez les notes d’incident ensemble, dans un dossier ou un fichier, avec un court index. Lisez-les à la revue trimestrielle. Les motifs entre incidents sont souvent plus révélateurs qu’aucun incident isolé : le même genre de vérification manque sans cesse, le même genre de modification tourne sans cesse mal, la même partie de l’activité reste fragile. Ces motifs désignent les améliorations qui comptent le plus.

Les agents peuvent aider à écrire les notes d’incident. Donnez à l’un d’eux la chronologie, les diffs concernés et le brief, et demandez-lui de rédiger les trois sections. Son brouillon identifiera souvent des causes contributives auxquelles vous n’aviez pas pensé. Mais relisez-le attentivement, surtout le pourquoi, car les causes les plus importantes sont souvent des choses que l’agent ne peut pas voir : vos hypothèses, votre pression de temps, votre connaissance du client.

Cette semaine, si quelque chose d’important tourne mal, écrivez la note : ce qui s’est passé, pourquoi, ce qui change. Si rien ne tourne mal, écrivez-en une pour l’incident le plus important du mois écoulé. Puis menez les actions. La note n’est que la première moitié. Les changements sont le but.

Sans blâme, même seul

Les équipes qui gèrent bien les incidents adoptent généralement un principe appelé « culture sans blâme » : l’analyse d’un incident sert à comprendre et améliorer le système, pas à trouver un coupable. Les gens qui craignent d’être blâmés cachent des informations, et les informations cachées dégradent le système. On pourrait croire que ce principe ne s’applique pas à un opérateur solitaire, puisqu’il n’y a personne d’autre à blâmer que soi-même. En réalité, il s’applique avec une force particulière, car la personne la plus susceptible de vous blâmer, c’est vous.

L’auto-accusation est corrosive d’une façon précise. Quand quelque chose tourne mal et que votre première réaction est j’aurais dû le voir, quel idiot, vous risquez de faire l’une de deux choses. Soit vous corrigez vite et passez à autre chose, en évitant l’inconfort de regarder de près, ce qui veut dire que vous n’apprenez jamais la cause. Soit vous ressassez, en rejouant l’erreur, ce qui épuise énergie et attention sans rien améliorer. Aucune des deux ne mène à l’analyse calme et curieuse qui empêche réellement la récidive.

La culture sans blâme vit à l’intersection de l’honnêteté et de la bienveillance. Honnêteté, parce qu’il faut regarder clairement ce qui s’est passé, y compris votre propre part, sans minimiser ni excuser. Bienveillance, parce que vous abordez ce regard lucide avec la même bonne volonté que vous offririez à un collègue ayant commis la même erreur : en supposant qu’il faisait de son mieux avec ce qu’il savait à ce moment-là, et en vous concentrant sur ce qui l’aurait aidé à mieux faire.

Regardez le système qui l’a permis, pas la personne qui se trouvait le plus près.

En pratique, cela signifie écrire les notes d’incident et les journaux d’erreurs sur un certain ton. Non pas j’ai négligemment oublié de vérifier le cas vide, mais le cas vide n’a pas été vérifié ; le brief ne le mentionnait pas et aucun test ne le couvrait. Les deux sont vrais. La seconde formulation désigne des choses que vous pouvez changer. La première ne désigne qu’un sentiment. Il ne s’agit pas d’éluder la responsabilité. Vous restez l’opérateur, et c’est toujours votre nom qui est sur la porte. Il s’agit d’orienter la responsabilité là où elle peut servir à quelque chose.

La culture sans blâme s’étend aussi aux agents, d’une façon curieuse. Quand un agent commet une erreur, il est tentant de la mettre sur son compte et de passer à autre chose, ou de perdre confiance dans les agents en général. Une approche sans blâme se demande ce qui, dans le système, a permis l’erreur : le brief, les autorisations, les vérifications, la mémoire. Cette question a presque toujours une réponse utile. L’agent avait tort n’en a presque jamais, car on ne peut pas corriger le caractère d’un agent, seulement les conditions dans lesquelles il travaille.

Il y a un bénéfice pratique au-delà d’un meilleur apprentissage : vous vous sentez mieux, et un opérateur qui se sent mieux prend de meilleures décisions. L’auto-accusation est une forme de stress, et le stress rétrécit l’attention et dégrade le jugement. Un opérateur capable de regarder une erreur calmement, d’en tirer la leçon et de passer à autre chose est en bien meilleure forme pour la décision suivante que celui qui traîne l’erreur pendant des jours.

Cette semaine, relisez les dernières choses que vous avez écrites sur vos propres erreurs, notes d’incident, entrées de carnet ou simplement ce que vous vous êtes dit. Remarquez le ton. S’il est dur, réécrivez l’une d’elles sans blâme : ce qui s’est passé, ce qui dans le système l’a permis, ce qui va changer. Voyez si la version réécrite désigne une meilleure correction. C’est généralement le cas.

Des garde-fous nés des cicatrices

Les meilleurs garde-fous d’une activité n’ont pas été conçus à l’avance. Ils ont été appris. Chacun est le résidu de quelque chose qui a mal tourné : une cicatrice devenue leçon, devenue règle. L’opérateur qui transforme systématiquement ses cicatrices en garde-fous finit avec une activité résistante précisément aux erreurs auxquelles elle est le plus sujette, ce qui protège bien mieux que n’importe quel ensemble générique de bonnes pratiques.

La chaîne est simple. Quelque chose tourne mal et laisse une cicatrice : une livraison cassée, un après-midi perdu, un message embarrassé envoyé à un client. La note d’incident en extrait la leçon : pourquoi c’est arrivé, ce qui l’aurait empêché. Puis la leçon devient un garde-fou : quelque chose de concret dans le système qui rend l’erreur plus difficile, voire impossible, la fois suivante. Le garde-fou est le bénéfice. Sans lui, la leçon n’est qu’une chose dont on espère se souvenir, et la mémoire, comme ce livre ne cesse de le répéter, n’est pas une chose sur laquelle compter.

Les garde-fous prennent plusieurs formes, des plus souples aux plus rigides. Une ligne dans un fichier de mémoire ou une recette, qui dit aux agents d’éviter quelque chose ou de toujours vérifier quelque chose. Une étape dans une liste de contrôle, comme la commande de fin ou la note de livraison. Un test qui échoue si l’erreur se reproduit. Une autorisation qui empêche l’action dangereuse. Une vérification dans la chaîne de livraison qui bloque la fusion. Un hook ou une règle automatique qui intervient au moment du risque. Proportionnez la rigidité à la gravité de la cicatrice.

Chaque règle d’une bonne activité a une histoire derrière elle. Veillez à ce que les vôtres en aient une.

Les garde-fous souples sont bon marché et faciles à ajouter, et ce sont le bon choix pour les erreurs mineures. Une ligne en mémoire disant toujours vérifier que les dates sont dans le fuseau horaire de l’utilisateur suffit pour une erreur qui a causé une petite confusion une fois. Les garde-fous rigides demandent plus d’effort et sont le bon choix pour les erreurs graves ou répétées. Si un secret a été commité une fois, un détecteur de secrets qui bloque les push est un garde-fou rigide qui rend la récidive presque impossible, et il vaut l’effort de mise en place.

Gardez l’histoire avec le garde-fou. Quand vous ajoutez une règle à un fichier de mémoire, ajoutez une brève note expliquant pourquoi : ajouté après l’incident d’export de mars. Quand vous ajoutez une vérification, faites référence à la note d’incident. Cela compte pour deux raisons. Cela vous permet, plus tard, de juger si le garde-fou est encore nécessaire ; si la cause sous-jacente a été corrigée, il peut être retiré. Et cela empêche le garde-fou de paraître arbitraire, à vous ou à quiconque, ce qui le rend plus susceptible d’être respecté.

Les garde-fous peuvent aussi s’accumuler en fouillis, comme tout le reste. Un fichier de mémoire de cinquante règles, chacune issue d’une cicatrice différente, peut devenir difficile à suivre pour les agents et difficile à entretenir pour vous. Élaguez les garde-fous à la revue trimestrielle, comme vous élaguez la mémoire. Retirez ceux dont les causes ont disparu. Promouvez les garde-fous souples qui restent sans cesse nécessaires en garde-fous rigides qui s’appliquent d’eux-mêmes. Fusionnez ceux qui se recoupent.

Cette semaine, regardez vos trois derniers incidents ou erreurs importantes. Pour chacun, vérifiez si un garde-fou a été ajouté. Sinon, ajoutez-en un, en choisissant sa rigidité selon la gravité. Gardez l’histoire avec lui. Cicatrice après cicatrice, l’activité prend la forme de sa propre expérience.

L’habitude du runbook

Un runbook est une procédure écrite pour faire quelque chose : déployer un projet, restaurer une sauvegarde, changer un identifiant, accueillir un nouveau client, installer une machine neuve. Les grandes organisations tiennent des runbooks parce que beaucoup de gens doivent exécuter les mêmes tâches de façon cohérente. Un opérateur solitaire en a besoin pour une autre raison : la personne qui exécutera la tâche la prochaine fois, c’est vous, dans des mois, ayant oublié tous les détails.

L’habitude est simple. Si vous avez fait quelque chose deux fois et comptez le refaire, écrivez-le. Pas un document léché, juste les étapes dans l’ordre, une vérification après chaque étape pour confirmer qu’elle a marché, et la façon de revenir en arrière si quelque chose tourne mal. C’est cela, le runbook. Gardez-le en texte brut, avec le projet ou à côté de vos recettes.

Le déclencheur, « fait deux fois », est important. Écrire un runbook après avoir fait quelque chose une seule fois tend à saisir les particularités de cette occasion plutôt que la procédure générale. L’écrire après la deuxième fois saisit ce qui était commun aux deux, c’est-à-dire la procédure. L’écrire après la cinquième fois signifie que vous avez passé la troisième, la quatrième et la cinquième à reconstituer ce que vous aviez oublié. Deux fois, c’est le point idéal.

La personne qui aura besoin du runbook, c’est vous, un mauvais jour, ayant tout oublié.

La vérification après chaque étape est ce qui distingue un runbook d’une liste d’instructions. Les instructions vous disent quoi faire. Un runbook vous dit aussi comment savoir que cela a marché : après le déploiement, ouvrir la page de contrôle de santé et confirmer qu’elle affiche la nouvelle version. Sans vérifications, un runbook peut être suivi à la lettre et produire quand même un résultat cassé, parce qu’une étape a échoué en silence et que rien ne vous l’a signalé.

La section de retour arrière est ce qui rend un runbook sûr à suivre sous pression. Si une étape échoue en cours de route, il faut savoir s’il faut continuer, réessayer ou revenir en arrière, et si l’on revient, comment. L’écrire à l’avance, à tête reposée, vaut bien mieux que de le déterminer sur le moment. Pour beaucoup de procédures de routine, le retour arrière est trivial. Pour certaines, c’est la partie la plus importante du document.

Runbooks et recettes sont proches cousins, et la frontière entre eux est floue. Une recette est un brief pour un agent ; un runbook est une procédure, qui peut être suivie par vous ou par un agent. Beaucoup d’opérateurs constatent que leurs runbooks deviennent peu à peu exécutables par des agents : les étapes sont assez claires pour qu’un agent puisse les suivre, vous relisant les vérifications. C’est une bonne direction, tant que le runbook reste lisible par un humain le jour où l’agent n’est pas disponible.

Testez les runbooks de temps en temps. Un runbook qui n’a pas été suivi depuis six mois peut renvoyer à des étapes qui ont changé, des outils qui ont bougé ou des réglages qui n’existent plus. Le calendrier d’entretien est un bon endroit pour planifier une répétition périodique des plus importants : déployer, restaurer, changer les identifiants. Corrigez tout ce qui est périmé.

Cette semaine, trouvez une procédure que vous avez faite au moins deux fois et écrivez son runbook : étapes, vérifications, retour arrière. Puis suivez-le une fois, exactement tel qu’écrit, et corrigez ce que vous trouvez. Vous serez surpris du nombre de petits détails que votre mémoire complétait discrètement. Le runbook les contient désormais, ce qui veut dire que votre mémoire n’a plus à le faire.

La file des décisions

Tout opérateur a un arriéré de tâches. Moins nombreux sont ceux qui comprennent qu’ils ont aussi un arriéré de décisions, et que c’est ce second arriéré qui limite réellement l’activité. Les tâches peuvent être déléguées ; les agents en traiteront volontiers une longue liste. Les décisions, non. Chaque fil qui attend votre réponse, chaque projet qui attend que vous choisissiez une direction, chaque relecture qui attend votre verdict est une décision en file d’attente, et la longueur de cette file est la vraie mesure de ce que l’activité attend de vous.

Rendre la file des décisions visible est la première étape. La plupart des opérateurs la portent dans leur tête, ce qui signifie qu’ils ne voient pas sa longueur et ne peuvent pas y établir de priorités. Écrivez-la. Une seule liste, avec une ligne par décision en suspens : ce qu’il faut décider, ce que cela bloque, et pour quand il faut décider. Incluez les petites comme les grandes, car les petites décisions non prises bloquent les fils tout aussi efficacement que les grandes.

Tout ce qui ressemble à une décision n’en est pas une. Les agents posent énormément de questions, et beaucoup trouvent leur réponse dans le brief, la mémoire ou une politique permanente. Chaque fois que vous vous surprenez à répondre deux fois à la même question, c’est le signe qu’elle a sa place en mémoire plutôt que dans la file. Chaque fois que vous vous surprenez à trancher une chose qu’une politique claire réglerait, écrivez la politique. La file devrait se resserrer, de tout ce que demandent les agents aux vraies décisions qui ont besoin de vous, jusqu’aux quelques-unes à prendre aujourd’hui.

Votre arriéré de tâches, c’est le problème des agents. Votre arriéré de décisions, c’est le vôtre.

Traitez la file délibérément. Pendant la revue du matin, regardez-la et choisissez les décisions qui débloquent le plus. Prenez-les en premier, dans vos meilleures heures. Les décisions qui bloquent plusieurs fils valent bien plus que celles qui n’en bloquent qu’un. Les décisions assorties d’une échéance passent avant celles qui n’en ont pas. Et les décisions faciles doivent être prises immédiatement, car une décision facile laissée dans la file coûte autant d’attention qu’une difficile, chaque fois que vous la regardez.

Beaucoup de décisions traînent non parce qu’elles sont difficiles, mais parce qu’elles sont inconfortables : dire non à quelqu’un, mettre fin à un projet, admettre qu’une direction était mauvaise. Celles-là ont tendance à couler au fond de la file et à y rester. Repérez-les. Une décision qui se trouve dans la file depuis plus d’une semaine est presque toujours de cette espèce, et l’inconfort de la prendre est presque toujours moindre que le coût de la laisser traîner. Les chapitres suivants y reviennent.

Cette semaine, écrivez votre file des décisions. Chaque décision en suspens, avec ce qu’elle bloque et son échéance. Puis, chaque matin, prenez les trois qui débloquent le plus. En fin de semaine, comparez la longueur de la file à celle du départ. Si elle a raccourci, l’activité aura avancé plus vite, car ce qu’elle attendait surtout, c’était vous.

Portes à sens unique et portes battantes

Les décisions diffèrent par la facilité avec laquelle on peut les défaire. Certaines sont des portes battantes : on peut les franchir, jeter un œil, et revenir sur ses pas si l’on n’aime pas ce qu’on voit. Essayer une nouvelle mise en page, ajuster une recette, choisir sur quel projet travailler cette semaine, retenir un outil pour un essai. D’autres sont des portes à sens unique : une fois franchies, on ne peut pas facilement revenir. Supprimer des données, signer un contrat, publier quelque chose pour un large public, s’engager publiquement sur une échéance, mettre fin à une relation client.

La distinction compte, car les deux espèces méritent des traitements très différents. Les portes battantes doivent se décider vite. Le coût d’un mauvais choix est faible, puisqu’on peut revenir en arrière, et le coût d’une décision lente est réel, puisque l’activité attend. Recueillir davantage d’informations ou délibérer plus longtemps améliore rarement une décision réversible au point de justifier le délai. Tranchez, regardez ce qui se passe, ajustez.

Les portes à sens unique méritent davantage de soin. Ici, le coût d’un mauvais choix peut être lourd et permanent, et une certaine délibération en vaut la peine. Recueillez les éléments qui comptent. Dormez dessus si vous le pouvez. Demandez à un agent de plaider la thèse adverse. Cherchez des moyens de rendre la décision plus réversible, comme le suggérait le chapitre sur la livraison et la finition : une période d’essai, une petite livraison, une sauvegarde, un engagement progressif.

La plupart des décisions sont des portes battantes déguisées en portes à sens unique. Vérifiez les gonds.

Pensez les décisions selon deux axes : leur réversibilité et leur enjeu. Les décisions réversibles à faible enjeu sont celles qu’il faut prendre vite pour passer à autre chose. Ce quadrant contient la plupart des décisions d’un opérateur, ce qui signifie que la plupart des décisions doivent être rapides. L’échec courant consiste à les traiter comme si elles se trouvaient dans le coin irréversible à fort enjeu, et à délibérer sur des choix qu’on pourrait simplement essayer et réviser.

L’échec inverse se produit aussi, surtout avec des agents. Parce que les agents rendent l’action si facile, il est possible de franchir une porte à sens unique à la vitesse d’une porte battante. Une suppression exécutée par un agent en quelques secondes est aussi irréversible qu’une suppression faite à la main. Un e-mail envoyé par une recette atteint tout le monde tout autant. La politique d’autorisations et son niveau « demander d’abord » existent en grande partie pour ralentir les portes à sens unique, afin qu’elles reçoivent la délibération qu’elles méritent.

Une habitude utile consiste à étiqueter les décisions au moment de les ajouter à la file : sens unique ou battante. L’étiquette vous dit combien de temps y consacrer. Les décisions battantes reçoivent une minute et un choix. Les décisions à sens unique reçoivent une vraie attention, idéalement dans vos meilleures heures, avec des preuves et une nuit de sommeil quand c’est possible. Avec le temps, vous remarquerez que l’étiquette « battante » s’applique bien plus souvent que votre instinct ne le laissait croire.

Cette semaine, étiquetez chaque décision de votre file. Prenez aujourd’hui toutes les décisions battantes, vite, sans vous torturer. Accordez aux décisions à sens unique le temps qu’il leur faut. Remarquez combien la file raccourcit, et combien peu de décisions rapides vous regrettez ensuite. Celles que vous regrettez, vous pouvez les défaire. C’était tout l’intérêt.

Dire non aux bonnes idées

Les agents sont généreux en idées. Demandez à l’un d’eux de passer un projet en revue, et il suggérera des améliorations. Demandez-lui d’étudier un marché, et il repérera des opportunités. Demandez-lui de corriger un bug, et il mentionnera peut-être trois autres choses qui vaudraient la peine d’être faites pendant qu’il y est. La plupart de ces idées sont bonnes. C’est précisément le problème. Un opérateur qui dit oui à chaque bonne idée ne finira jamais rien, car il y aura toujours une autre bonne idée qui arrive plus vite que la précédente ne peut être menée à terme.

Le savoir-faire ne consiste donc pas à distinguer les bonnes idées des mauvaises. Les mauvaises idées sont faciles à décliner. Le savoir-faire consiste à dire non, ou pas encore, aux bonnes idées, parce qu’elles ne correspondent pas aux priorités du moment, parce qu’il n’y a pas d’attention disponible pour elles cette semaine, ou parce que finir ce qui est déjà commencé vaut davantage. C’est plus difficile qu’il n’y paraît, car chaque bonne idée arrive avec sa petite lueur de possible, et la décliner ressemble à une perte.

Il est utile de se rappeler ce que coûte réellement un oui. Chaque idée nouvelle qui devient un projet prend une place au registre, une part de votre attention, des fils à briefer et à relire, et finalement des décisions sur son avenir. Le coût n’est pas le temps de l’agent, qui ne vaut presque rien. C’est le vôtre, qui vaut beaucoup. Un oui à une idée nouvelle est un non silencieux à autre chose, généralement à la chose que vous étiez censé finir.

Les agents génèrent des options. Le travail de l’opérateur est de les élaguer.

Dire non ne signifie pas perdre l’idée. La file existe précisément pour cela. Notez l’idée en une ligne, indiquez d’où elle vient, et laissez-la concourir à la prochaine revue hebdomadaire ou trimestrielle avec tout le reste. Beaucoup de bonnes idées, après quelques semaines dans la file, se révèlent moins convaincantes qu’elles ne le semblaient. Quelques-unes se révèlent meilleures encore, et elles démarrent au moment de votre choix, avec une vraie attention, plutôt que d’être coincées dans une semaine déjà pleine.

Certains opérateurs trouvent utile de s’en tenir à une règle simple : aucun nouveau projet ne démarre tant qu’un projet existant n’est pas fini ou mis en sommeil. Un qui entre, un qui sort. Elle impose la comparaison qu’exige le refus : cette idée nouvelle vaut-elle mieux que la plus faible des choses que je fais tourner actuellement ? Si oui, échangez-les. Sinon, l’idée nouvelle attend. La règle transforme un vague inconfort en décision claire.

Il vaut aussi la peine d’informer les agents de votre appétit pour les idées. Une ligne en mémoire comme note les autres améliorations à la fin de ton compte rendu ; ne les mets pas en œuvre garde le flux d’idées ouvert sans les laisser s’infiltrer dans le travail. Vous profitez des suggestions de l’agent sans payer le prix d’un périmètre incontrôlé.

Cette semaine, comptez les bonnes idées qui vous arrivent, des agents, de vos lectures, de votre propre tête. Dites oui à une seule au maximum. Mettez les autres en file. En fin de semaine, lisez la file. Remarquez quelles idées paraissent encore enthousiasmantes et lesquelles ont pâli. Celles qui ont pâli, c’est l’attention que vous avez économisée en disant non.

Décider sur des preuves partielles

Les chapitres précédents ont insisté sur les preuves : des preuves plutôt que des assurances, des preuves à chaque relecture, des preuves avant chaque livraison. Cela reste vrai. Mais il existe un piège de l’autre côté, et les opérateurs consciencieux y tombent souvent : attendre des preuves complètes avant de décider. Les preuves complètes arrivent rarement. La plupart des décisions doivent se prendre avec ce qu’on a, et le savoir-faire consiste à savoir quand ce qu’on a suffit.

« Assez », c’est là où deux choses se rencontrent : les preuves dont vous disposez et le temps dont vous disposez. Davantage de preuves serait toujours appréciable. Davantage de temps aussi. Mais à un certain point, la valeur de preuves supplémentaires est dépassée par le coût de l’attente, et c’est à ce point qu’il faut décider. Il arrive plus tôt pour les portes battantes que pour les portes à sens unique, plus tôt pour les décisions à faible enjeu que pour celles à fort enjeu, et plus tôt que ne le ressentent instinctivement la plupart des gens soigneux.

Les agents rendent ce piège plus facile, car ils rendent la collecte de preuves si bon marché. On peut toujours demander une analyse de plus, une comparaison de plus, une recherche de plus. Chacune est rapide et chacune paraît responsable. Mais chacune retarde aussi la décision, et l’activité attend. À un certain point, demander davantage de recherches devient une façon d’éviter l’inconfort de s’engager, et la recherche ne sert plus la décision. Elle la remplace.

La question n’est pas de savoir si vous en savez assez pour être certain. C’est de savoir si vous en savez assez pour agir.

Un test utile consiste à se demander quelle preuve vous ferait changer d’avis. Si vous pouvez la nommer et l’obtenir dans un délai raisonnable, obtenez-la. Si vous ne pouvez rien nommer qui vous ferait changer d’avis, vous avez déjà décidé et ne faites que retarder l’annonce. Si la preuve qui vous ferait changer d’avis est inaccessible, ou prendrait plus de temps à obtenir que la décision ne peut en attendre, décidez maintenant avec ce que vous avez.

Un autre test consiste à imaginer que la décision tourne mal et à se demander si davantage de preuves l’aurait évité. Parfois oui : une vérification rapide des données aurait montré le problème. Souvent non : le résultat dépendait de choses impossibles à connaître à l’avance. Dans le second cas, attendre n’aurait pas aidé, et décider promptement vous a au moins donné plus de temps pour remarquer et ajuster.

Quand vous décidez sur des preuves partielles, dites-le, dans le journal des décisions. Décidé de poursuivre avec la petite version ; les données sur la demande sont minces, mais attendre un mois de plus coûterait davantage. À réexaminer après les deux premières semaines d’usage. Cela consigne honnêtement l’incertitude et prévoit un moment pour vérifier si la décision a tenu. Cela vous protège aussi, plus tard, du faux souvenir d’avoir été plus certain que vous ne l’étiez.

Cette semaine, regardez la plus ancienne décision de votre file. Demandez-vous quelle preuve vous ferait changer d’avis. Si vous pouvez l’obtenir aujourd’hui, obtenez-la. Sinon, décidez maintenant, notez l’incertitude et fixez une date pour y revenir. Remarquez que le monde ne s’est pas effondré. Il s’effondre rarement, et l’activité se remet en mouvement.

Le prix de l’indécision

Ne pas décider donne l’impression de garder des options ouvertes. Ce n’est pas le cas. Ne pas décider est en soi une décision, généralement mauvaise, prise par défaut plutôt que par choix. Quand vous laissez une décision en suspens, le monde n’attend pas. Les choses dérivent, les circonstances changent, et finalement il se passe quelque chose qui tranche la question pour vous, rarement comme vous l’auriez choisi.

Le motif est fiable. Vous différez une décision, parce qu’elle est inconfortable, ou que vous voulez plus d’informations, ou qu’elle ne semble pas urgente. Pendant qu’elle est différée, l’activité dérive autour d’elle. Les fils qui en dépendent calent ou avancent sur des hypothèses. D’autres décisions sont prises qui supposent une réponse ou l’autre. Le temps passe et les options se ferment en silence. Finalement, un défaut l’emporte : le projet meurt de négligence, le client fait le choix à votre place, l’échéance arrive et impose ce qui se trouve le plus à portée de main. La décision a été prise. Simplement, ce n’est pas vous qui l’avez prise.

Les coûts de l’indécision sont pour la plupart invisibles, et c’est pourquoi on les encourt si facilement. Personne ne vous envoie de facture pour la semaine où un projet a calé en vous attendant. Personne ne vous fait remarquer que trois fils ont avancé sur une hypothèse fausse parce que la décision dont ils avaient besoin n’était pas là. Mais ces coûts sont réels, et dans une activité d’une seule personne, ils retombent entièrement sur vous.

Si vous ne décidez pas, quelque chose d’autre le fera. Et ce quelque chose n’aura pas vos intérêts à cœur.

Il y a aussi un prix émotionnel. Les questions non tranchées restent dans l’esprit et génèrent une anxiété sourde. Elles refont surface à des moments étranges, sous la douche, à trois heures du matin, au milieu d’un travail sans rapport. Elles rendent la file des décisions plus lourde qu’elle ne l’est. Beaucoup d’opérateurs constatent que prendre une décision longtemps différée, même imparfaite, procure un soulagement immédiat et disproportionné. Ce soulagement, c’est le coût qu’ils payaient sans s’en apercevoir.

Le remède n’est pas de tout décider instantanément ; certaines décisions gagnent réellement à mûrir. C’est de faire du report une décision, lui aussi. Quand vous choisissez de ne pas décider quelque chose maintenant, notez quand vous le déciderez et ce que vous attendez. Décision sur le changement de tarifs le quinze, après la première semaine de données d’usage. C’est un report délibéré, et c’est très bien. Ce qui ne va pas, c’est le j’y réfléchirai sans limite, par lequel les décisions dérivent vers les défauts.

La revue hebdomadaire est un bon endroit pour attraper les décisions qui dérivent. Cherchez dans la file des décisions tout ce qui s’y trouve depuis plus d’une semaine sans date. Chacune est soit un report délibéré auquel manque sa date, soit une décision qui dérive. Donnez une date aux premières. Prenez les secondes maintenant.

Cette semaine, trouvez la décision que vous évitez depuis le plus longtemps. Prenez-la, aujourd’hui, avec les preuves dont vous disposez. Notez ce que vous avez décidé et pourquoi. Puis remarquez le soulagement, et les fils qui se remettent en mouvement. C’est le prix de l’indécision, remboursé.

Le jugement ne se délègue pas

À mesure que les agents gagnent en capacité, la frontière de ce qu’ils savent faire ne cesse de reculer. Des tâches qui demandaient une personne l’an dernier sont devenues routinières pour un agent cette année. Il est naturel de se demander si la frontière finira par tout englober, et si le rôle de l’opérateur se réduira à rien. Ce ne sera pas le cas, et il vaut la peine d’en comprendre clairement la raison, car elle vous dit où investir votre propre développement.

Pensez le travail comme une pile. Tout en bas, la façon dont il est fabriqué : écrire, coder, concevoir, chercher. Cette couche est de plus en plus délégable, et les agents en prennent davantage en charge chaque mois. Au-dessus, la question de savoir s’il est livré : la relecture, le niveau d’exigence, la décision de livrer. Les agents peuvent considérablement éclairer cette couche, en lançant des vérifications, en comparant des options, en signalant des risques, mais la décision porte votre nom. Au-dessus encore, ce que « bon » veut dire : les exigences, le goût, la définition de « fini » pour ce travail précis, pour ces personnes précises. Et au sommet, pourquoi cela compte : quels problèmes valent la peine d’être résolus, quels projets valent la peine d’être menés, à quoi sert l’activité.

Les couches supérieures résistent à la délégation, non que les agents soient incapables d’avoir un avis à leur sujet. Les agents peuvent produire des avis parfaitement sensés sur à peu près tout. Elles résistent à la délégation parce qu’elles dépendent de choses que vous seul possédez : vos relations, vos valeurs, votre connaissance de votre propre situation, votre disposition à répondre du résultat. Un agent peut proposer une raison pour laquelle un projet compte. Il ne peut pas se soucier de savoir s’il compte, et il ne peut pas être tenu pour responsable s’il s’est trompé.

Les agents peuvent vous dire ce qui est possible. Vous seul pouvez dire ce qui en vaut la peine.

Cela a des conséquences pratiques sur la façon d’employer votre propre temps d’apprentissage. La couche du bas est celle où les agents progressent le plus vite, et y investir massivement dans vos propres compétences rapporte de moins en moins. Les couches supérieures sont celles où votre jugement est irremplaçable, et elles récompensent l’investissement : mieux comprendre vos utilisateurs, affûter votre goût, clarifier ce que vous cherchez à accomplir, apprendre à décider plus vite et mieux. Ce sont les compétences qui vous rendent plus précieux à mesure que les agents s’améliorent, pas moins.

Cela a aussi des conséquences sur votre façon d’utiliser les agents. Déléguez librement le bas de la pile. Servez-vous abondamment des agents pour éclairer le milieu, en demandant options, preuves et critiques. Servez-vous-en avec parcimonie et prudence au sommet, comme interlocuteurs plutôt que comme décideurs. Un opérateur qui demande à un agent quels projets mener, puis se contente de les mener, n’a pas délégué son jugement. Il l’a abandonné.

Rien de tout cela n’est un appel à la méfiance. Les agents sont des collaborateurs extraordinaires à chaque couche. Il s’agit seulement de comprendre que collaborer et déléguer sont deux choses différentes. On peut collaborer sur le jugement. On ne peut pas le céder, car dès l’instant où on le cède, on n’est plus l’opérateur. On est un passager.

Cette semaine, regardez les décisions que vous avez prises et demandez-vous, pour chacune, à quelle couche de la pile elle appartenait. Remarquez où vous vous êtes appuyé sur les agents et où vous ne l’avez pas fait. Si vous constatez que vous déléguez les couches du haut, reprenez-les. Si vous constatez que vous faites encore vous-même la couche du bas, lâchez-la. La pile se trie d’elle-même dès qu’on la voit.

Enseigner ce qu’on fait tourner

Une vieille observation veut qu’on ne comprenne vraiment une chose qu’une fois capable de l’enseigner. Pour un opérateur, elle a un tranchant pratique. Mettre par écrit le fonctionnement de votre activité, assez clairement pour que quelqu’un d’autre puisse le suivre, est l’une des meilleures façons de découvrir ce que vous faites réellement, ce que vous croyez seulement faire, et où sont les trous. Enseigner ce qu’on fait tourner est une façon de mieux le faire tourner.

La forme évidente est la documentation destinée à un collaborateur. Si vous faites un jour entrer quelqu’un dans votre activité, même brièvement, il vous faudra expliquer comment elle fonctionne : le rythme, le registre, les recettes, les exigences de relecture, le processus de livraison. Écrire cette explication impose une clarté que la pratique quotidienne n’impose pas. Vous découvrez des habitudes que vous n’aviez jamais formulées, des règles appliquées de façon incohérente et des étapes qui n’avaient de sens que parce que vous en connaissiez l’histoire.

Mais nul besoin d’un collaborateur pour en profiter. Écrire pour un nouveau venu imaginaire marche presque aussi bien. Écrire pour des agents aussi, et c’est en un sens ce que sont déjà les fichiers de mémoire et les recettes : des documents pédagogiques pour un élève très rapide, très littéral, qui oublie tout pendant la nuit. Un opérateur qui écrit de bons fichiers de mémoire enseigne déjà, et peut étendre l’habitude à l’activité entière.

Expliquer votre système à quelqu’un d’autre est le moyen le plus rapide de découvrir ce qu’il est.

L’enseignement prend plusieurs formes, rassemblées autour du même centre. L’écrire : mettre l’activité en mots, dans un manuel à vous. L’expliquer : la décrire à voix haute à quelqu’un, ce qui révèle d’autres trous que l’écriture. Le partager : en publier des parties, ce qui suscite des questions que vous ne vous seriez jamais posées. Et l’affiner : utiliser ce que vous avez appris en écrivant, expliquant et partageant pour améliorer l’activité elle-même. Chacune nourrit les autres.

Le partage, en particulier, est sous-estimé par les opérateurs solitaires, qui ont tendance à juger leurs méthodes trop idiosyncrasiques pour intéresser qui que ce soit. Ils ont généralement tort. D’autres personnes qui mènent des activités semblables affrontent des problèmes semblables et sont souvent heureuses de voir comment quelqu’un d’autre les a résolus. Et le fait de préparer quelque chose pour d’autres lecteurs élève votre propre exigence : vous ne publierez pas la description de votre processus de livraison sans vous assurer d’abord que c’est un processus dont vous seriez fier.

Il y a un bénéfice supplémentaire pour un opérateur solitaire. Un récit écrit du fonctionnement de votre activité est une assurance. Si vous êtes malade, en vacances ou simplement absent un moment, ce récit vous permet, à vous ou à quiconque vous aide, de reprendre les fils. C’est le runbook de l’activité elle-même, au plus haut niveau, et comme tout runbook, il n’est utile que s’il a été écrit avant d’être nécessaire.

Cette semaine, écrivez une page expliquant le fonctionnement de votre journée d’exploitation pour un nouveau venu imaginaire : la revue, les sessions, la clôture, le registre, votre façon de briefer et de relire. Soyez précis. Puis relisez-la et marquez tout ce qui vous a surpris, contredit ce que vous faites réellement ou s’est révélé difficile à expliquer. Ces marques sont vos prochaines améliorations. Vous vouliez enseigner, et vous avez fini par apprendre, ce qui est généralement ainsi que ça se passe.

L’opérateur de demain

Où va ce rôle ? Toute réponse honnête commence par l’incertitude. Les outils changent vite, les capacités des agents s’étendent de façons difficiles à prévoir, et quiconque prétend savoir exactement à quoi ressemblera la journée d’un opérateur solitaire dans quelques années devine avec aplomb. Mais la direction est visible, et elle suggère que le cœur de ce livre comptera davantage, pas moins.

La tendance, jusqu’ici, va vers des laisses plus longues. Les agents travaillent plus longtemps sans points de contrôle, prennent en charge des travaux plus gros, se coordonnent entre eux, tournent en arrière-plan et selon des calendriers, et assument une part croissante du jugement routinier qui demandait autrefois une personne. Chaque pas éloigne l’opérateur du faire et le rapproche des bords du travail : fixer l’intention au début et exercer le jugement à la fin.

Cette forme est le protocole au cœur du métier d’opérateur, et elle est déjà visible aujourd’hui. L’opérateur énonce l’intention : ce qu’on veut et pourquoi, avec une définition de « fini ». Les agents rendent le travail et la preuve : le résultat et l’élément qui montre qu’il répond à l’intention. Et l’opérateur exerce son jugement : est-ce bon, est-ce qu’on livre, quelle est la suite ? À mesure que les agents s’améliorent, le milieu de cet échange s’allonge et gagne en capacité. Le début et la fin restent à l’opérateur, et deviennent une part plus grande de ce qu’il fait.

Plus les agents en font, moins l’opérateur en fait, et plus ce qu’il fait compte.

Qu’est-ce que cela signifie pour les compétences qui valent d’être cultivées ? Une intention claire : la capacité à dire précisément ce que vous voulez, c’est-à-dire le brief, la définition de « fini », les contraintes. Un jugement sûr : la capacité à évaluer un travail et à décider quoi en faire, c’est-à-dire la relecture, le goût, la décision de livrer. Et un bon rythme : la capacité à structurer votre propre temps et votre attention pour que l’intention et le jugement s’exercent au mieux, c’est-à-dire la journée d’exploitation, la revue hebdomadaire, le budget d’énergie. Chaque partie de ce livre porte sur l’un de ces trois points.

Cela signifie aussi que le métier d’opérateur devient, à certains égards, plus humain. Quand le faire est délégué, ce qui reste est la part qui dépend du fait d’être une personne particulière, avec des relations, des valeurs et des responsabilités particulières. Comprendre ce dont un client a réellement besoin. Décider de ce qui vaut la peine d’être construit. Répondre du résultat. Ce ne sont pas des compétences techniques, et elles ne deviennent pas obsolètes quand la technologie progresse. Elles deviennent le métier.

Il y aura de nouveaux outils, de nouvelles pratiques et de nouveaux noms pour les choses, et certains détails de ce livre vieilliront. Traitez les détails comme des exemples et les principes comme la substance. Les principes, des briefs clairs, des preuves plutôt que des assurances, de petites livraisons, des traces honnêtes, un rythme soutenable, la responsabilité des résultats, sont plus anciens que les agents et survivront à toute version particulière de ceux-ci.

Cette semaine, demandez-vous lequel des trois, intention, jugement ou rythme, est votre point faible. Choisissez dans ce livre une pratique qui le renforce et adoptez-la pendant un mois. L’avenir du rôle récompensera l’opérateur qui s’est amélioré sur les bords pendant que le milieu s’automatisait. Commencez maintenant. Le milieu bouge déjà.

Le manuel comme habitude

Un manuel n’est pas fait pour être lu une fois. Il est fait pour servir : ouvert quand un problème précis se présente, consulté quand une habitude s’est relâchée, relu quand quelque chose ne marche pas et qu’on ne sait pas trop pourquoi. Celui-ci ne fait pas exception. Ses cent chapitres ne sont pas un cursus à terminer, mais un ensemble de pratiques à adopter, quelques-unes à la fois, et auxquelles revenir à mesure que votre activité change.

Le cycle qui transforme un manuel en habitude compte trois étapes. Lire un chapitre, ou une partie, quand c’est pertinent. Pratiquer ce qu’il suggère pendant une semaine ou deux, délibérément, dans votre travail réel. Puis réviser : décider si la pratique vous convient telle qu’elle est écrite, demande à être adaptée ou doit être abandonnée. Puis relire quand le problème suivant arrive. C’est la pratique qui compte. Lire sans pratiquer, c’est du divertissement. Pratiquer sans réviser, c’est de la rigidité. Le cycle a besoin des trois.

N’essayez pas de tout adopter d’un coup. Un opérateur qui commence la même semaine la revue du matin, la clôture, le registre, le journal des décisions, les notes de livraison, les notes d’incident et la revue hebdomadaire n’en gardera aucune. Choisissez une ou deux pratiques, celles qui s’attaquent à votre plus gros problème du moment, et donnez-leur un mois. Quand elles sont devenues automatiques, ajoutez-en une autre. Les habitudes capitalisent, mais seulement si elles survivent assez longtemps pour devenir des habitudes.

Lisez-le une fois pour les idées. Puis servez-vous-en pour la pratique.

Adaptez librement. Ce livre décrit des pratiques qui fonctionnent pour beaucoup d’opérateurs, mais votre activité est la vôtre. Peut-être votre revue marche-t-elle mieux à l’heure du déjeuner. Peut-être votre registre marche-t-il mieux sous forme de tableau. Peut-être les trois du jour devraient-ils être les deux du jour. Les principes comptent plus que les détails : décider exprès, briefer clairement, relire avec des preuves, livrer petit, écrire les choses, se reposer. La façon de les mettre en œuvre est à vous de la trouver, et c’est à l’étape de révision que vous le faites.

Tenez votre propre manuel à côté de celui-ci. À mesure que vous adaptez les pratiques, écrivez vos versions : votre liste de contrôle de la revue du matin, votre gabarit de brief, votre format de note de livraison, votre calendrier d’entretien. Avec le temps, votre propre manuel vous sera plus utile que celui-ci, car il épousera exactement votre activité. C’est le but. Ce livre est un point de départ, et un bon point de départ est un point de départ qu’on finit par dépasser.

Revenez-y à la revue trimestrielle. Parcourez les parties. Demandez-vous quelles pratiques vous avez adoptées, lesquelles vous avez laissées se relâcher et lesquelles vous n’avez jamais essayées. Choisissez-en une ou deux à travailler le trimestre suivant. Cela fait tourner le cycle à l’échelle de temps la plus longue, et cela signifie que chaque trimestre, votre activité est un peu plus délibérée que la précédente.

Cette semaine, choisissez dans ce livre le chapitre qui s’attaque à votre plus gros problème du moment. Pratiquez-le pendant deux semaines. Puis révisez : garder, adapter ou abandonner. Puis choisissez le suivant. Dans un an, vous aurez construit un système d’exploitation à votre mesure. Vous aurez aussi, très probablement, cessé d’avoir besoin de lire à son sujet, ce qui est le mieux qu’un manuel puisse espérer.

Le métier, c’est décider

Voici la thèse de ce livre, énoncée simplement : le vrai métier de l’opérateur, c’est de décider, pas de faire. Les agents font, chaque mois davantage, plus vite et mieux qu’aucune personne seule ne le pourrait. Ce qu’ils ne peuvent pas faire, c’est décider de ce qui vaut la peine d’être fait, de ce à quoi ressemble le bon, de la question de savoir si le résultat est assez bon pour porter votre nom, et de ce qui doit se passer ensuite. Ces décisions sont le métier. Tout le reste de ce livre n’est qu’une machinerie pour bien les prendre.

Déléguez le faire, parce que le faire est désormais délégable. Rédiger, construire, chercher, tester, résumer, ranger : confiez-les, avec un brief clair, des autorisations sensées et une définition de « fini ». Les garder par habitude ou par fierté n’est pas de la diligence. C’est dépenser votre ressource la plus rare, l’attention, sur la plus abondante, l’effort.

Relisez le travail, parce que la relecture est l’endroit où votre jugement y entre. Lisez le diff, vérifiez les preuves, appliquez les vérifications les moins chères d’abord et les plus profondes là où le risque l’exige. Demandez-vous si la forme est juste avant de polir le détail. Demandez-vous si c’est non seulement correct, mais vôtre. La relecture n’est pas une activité inférieure à la fabrication. C’est l’activité qui rend digne de confiance la chose fabriquée.

Et assumez la décision, parce que c’est la responsabilité qui fait fonctionner tout l’arrangement. Livrez ou renvoyez. Lancez le projet ou dites non. Mettez-le en sommeil ou mettez-y fin. Décidez sur les preuves que vous avez, vite quand la porte bat dans les deux sens et prudemment quand elle ne bat pas. Notez pourquoi. Puis vivez avec le résultat, tirez-en la leçon s’il tourne mal, et décidez de nouveau. C’est cela, un opérateur.

Les agents fournissent l’effort. Vous fournissez les décisions. C’est tout le métier.

Le reste de ce livre est au service de cela. La journée d’exploitation existe pour donner à la décision ses meilleures heures. Les briefs existent pour porter les décisions jusque dans le travail. La mémoire existe pour que les décisions n’aient pas à être prises deux fois. Le registre et la file des décisions existent pour que vous voyiez ce qui doit être décidé. La discipline de livraison existe pour que chaque décision de livrer soit petite et réversible. Les revues hebdomadaires et trimestrielles existent pour que vous décidiez de la direction au lieu d’y dériver. Le repos existe pour que celui qui décide soit en état de décider. Même les notes d’incident portent sur la décision : décider ce qu’il faut changer pour que l’erreur ne se répète pas.

C’est une bonne nouvelle, même si elle n’en a pas l’air au premier abord. Décider est à certains égards plus difficile que faire, moins tangible et moins immédiatement satisfaisant. Mais c’est aussi plus intéressant, plus humain et plus durable. Le faire continuera d’être automatisé. Le décider continuera d’avoir besoin de quelqu’un. Si vous y devenez bon, vous vaudrez davantage chaque année, pas moins.

Demain matin, donc, avant toute chose, ouvrez une page blanche et écrivez les trois décisions qui feraient le plus avancer votre activité. Puis prenez-les. Pas les tâches, les décisions. Laissez les agents s’occuper du reste. Vous découvrirez, comme bien des opérateurs avant vous, que le travail devient plus facile et le métier plus intéressant. Ce n’est pas une contradiction. C’est le métier, enfin vu clairement. Il a toujours consisté à décider. Les agents ont simplement retiré tout ce qui le cachait.