Ingénierie IA
En un mot

La fusion du matin

Le dernier chapitre de la configuration concerne les vingt minutes les plus importantes de ma semaine : la fusion du matin, lorsque je regarde ce que les courses de la nuit ont produit et que je décide de ce qui est assez bon à conserver.

J'ai dit que l'humain ne devrait être présent que là où il constitue la contrainte. La fusion du matin est l’exemple le plus clair d’un endroit où je me trouve véritablement. Du jour au lendemain, la machine se construit. Il suit le brief, il produit les artefacts, il laisse sa trace. Ce qu’il ne peut pas faire – ce que je n’ai délibérément pas essayé d’automatiser – c’est le jugement du goût : est-ce vraiment bon ? Est-ce qu'il est expédié ? La construction est délégable. Le is-this-good ne l'est pas, du moins pas encore, et prétendre le contraire est la façon dont vous finissez par expédier une médiocrité confiante.

La fusion est donc une révision, et elle est impitoyable. Le débit nocturne signifie que je me réveille avec plus que ce que je pourrais jamais expédier, ce qui ressemble à un luxe et est en fait un problème de discipline : lorsque la machine peut produire dix versions, l'acte rare est le rejet, pas la production. Mon travail le matin n'est pas de célébrer le volume. C'est pour en tuer la majeure partie. Les meilleurs matins consistent à jeter plus que ce que je garde, car jeter est désormais l’étape qui crée de la valeur – n’importe qui, ou n’importe quoi, peut générer ; choisir, c'est ce qu'il me reste.

Cela inverse l’ancienne relation entre effort et rendement. Quand j'ai construit moi-même, garder quelque chose n'était pas cher - j'avais déjà déployé des efforts pour le faire, alors bien sûr, je l'expédierais, coûts irrécupérables et tout. Désormais, la fabrication est libre et la conservation est une décision coûteuse, ce qui constitue le bon arrangement. L’effort doit reposer sur le jugement, pas sur la production. Le quart de nuit a déplacé l'effort exactement au bon endroit : je passe mes minutes les plus occupées à décider, pas à taper.

La fusion protège également le système d’un mode de défaillance spécifique, à savoir la dérive. Lorsqu'une machine produit en continu et que tout ce qu'elle fabrique est expédié, la qualité s'érode de manière invisible, un artefact acceptable mais pas génial à la fois, jusqu'à ce que l'ensemble de la production ait glissé quelque part que vous n'auriez jamais choisi d'aller délibérément. La fusion est la porte qui arrête le glissement. C'est un humain debout à la sortie qui dit pas ceci, pas ceci, celui-ci oui — et cette porte n'est aussi bonne que le goût et l'attention qui se cache derrière elle, c'est pourquoi elle obtient mes vingt minutes les plus fraîches et non mes dix dernières fatiguées.

C'est la configuration, les dix chapitres, et cela se résume à une seule forme : laisser la machine construire, pendant la nuit, sans surveillance, au volume – et se tenir à la porte le matin avec un regard neuf et une volonté de rejeter. Tout ce qui est technique dans les pièces qui suivent est au service de cette forme. Construisez sans vous. Jugez avec vous. Protégez le jugement.

L'échelle

Chaque système que j'ai construit repose sur l'un des trois échelons, et la plupart des problèmes que je me suis causés venaient du mauvais échelon - généralement un échelon trop haut, parfois un échelon trop bas. Donc, avant tout modèle spécifique, voici l'échelle elle-même, car savoir à quel échelon vous vous trouvez représente plus de la moitié de l'architecture.

L'échelon inférieur est l'artefact. Un seul fichier autonome (un composant React, une page HTML) qui s'exécute entièrement dans le navigateur, communique directement avec un modèle, n'a aucun secret et ne se souvient de rien entre les sessions. C'est la chose au monde la plus rapide à construire et la moins chère à jeter. Tout son travail est de rendre une idée visible suffisamment rapidement pour que quelqu'un puisse y réagir. L'erreur est de lui demander plus : au moment où vous souhaitez une authentification, un état partagé ou une exécution planifiée, l'artefact est sur le mauvais échelon et aucune intelligence n'en fera le bon.

L'échelon intermédiaire est sans serveur et possède une base de données hébergée. Vous disposez désormais d'un emplacement pour placer les secrets, d'un emplacement pour conserver l'état qui survit à une actualisation et d'un point de terminaison que d'autres choses peuvent appeler. C'est là que se trouvent réellement la plupart des produits réels, et c'est l'échelon que les gens franchissent avec trop d'empressement pour se diriger vers quelque chose qu'ils imaginent être plus « sérieux ». Pour un large éventail de tâches (authentification, stockage, surface API, mises à jour en temps réel), cette barre n'est pas un compromis, c'est la réponse. Il évolue plus loin que ce que les débutants attendent et coûte moins cher que ce qu’ils craignent.

L'échelon supérieur est un backend personnalisé sur une machine que vous contrôlez. Vous montez ici pour une seule raison : vous devez faire quelque chose que l'échelon intermédiaire ne peut pas structurellement faire. Processus de longue durée. Sous-processus de génération. Maintenir une connexion de streaming ouverte pendant quelques minutes. Exécuter une boucle d'agent qui réfléchit pendant un moment. Ce ne sont pas des préférences, ce sont des capacités que les échelons inférieurs n'ont pas, et le besoin d'en avoir ne serait-ce qu'une est ce qui justifie l'ascension : ni l'ambition, ni la propreté, ni le sentiment que de vrais ingénieurs gèrent leurs propres serveurs.

La discipline imposée par l'échelle est la suivante : grimpez uniquement lorsqu'une capacité dont vous avez réellement besoin vous y oblige, et jamais pour obtenir un statut. Chaque barreau vous coûte en poids opérationnel : plus à sécuriser, plus à surveiller, plus qui peut se briser à trois heures du matin. L'artefact ne peut pas divulguer de secret car il n'en détient aucun. Le backend personnalisé peut fuir de plusieurs manières. Ainsi, le bon échelon n'est pas celui qui est le plus performant, c'est celui qui est le moins performant et qui peut encore faire le travail, car c'est celui qui a la plus petite surface d'attaque et le moins à entretenir.

J'ai vu des gens - j'ai été la personne - créer un backend personnalisé pour quelque chose qu'une fonction sans serveur aurait géré, et payer pour cette vanité chaque jour en frais généraux d'exploitation. L'échelle est une question impérative, posée avant de construire : quel est l'échelon le plus bas qui peut réellement faire cela ? Commencez par là. Ne grimpez que lorsque la réalité, et non la vanité, vous pousse vers le haut.

Testez une fois, exposez deux fois

Voici l'habitude structurelle la plus utile que j'ai, et elle est d'une simplicité presque embarrassante : la logique réside au même endroit, et les moyens d'y parvenir sont de minces enveloppes qui ne contiennent aucune logique.

Concrètement. Il existe une couche de service : des fonctions simples, des classes simples, aucune importation de framework, aucune connaissance de la façon dont elles seront appelées. C'est là que se déroule le véritable travail : les règles métier, l'orchestration, ce que le système est pour. Ensuite, en l’enveloppant, il y a des points d’entrée. Une API Web que le navigateur peut appeler. Un outil de ligne de commande que je peux appeler. Peut-être plus tard, une tâche planifiée ou un gestionnaire de chatbot. Chaque point d'entrée ne fait presque rien : il analyse son type particulier d'entrée, appelle la couche de service et formate le résultat pour son type particulier de sortie. Toute l’intelligence est en bas ; tous les points d'entrée sont des traducteurs stupides.

Le nom que j'utilise pour le principe est tester une fois, exposer deux fois. Parce que la logique n'a pas d'enchevêtrement de framework, je peux la tester directement - appeler les fonctions, affirmer sur les résultats, pas de serveur Web, pas de moquerie d'un objet de requête, pas de harnais CLI. Et comme il est clairement séparé, l'exposer via une deuxième ou une troisième interface est presque gratuit : un nouveau point d'entrée est constitué de quelques lignes de traduction sur une logique qui fonctionne déjà et est déjà testée. Testez la partie la plus difficile une fois ; exposez-le autant de fois que vous avez d’audience.

Le mode de défaillance que cela évite est celui où la logique s’infiltre dans le point d’entrée – où le gestionnaire Web lui-même commence à prendre des décisions, à orchestrer et à maintenir des règles. Au moment où cela se produit, deux choses se brisent. Vous ne pouvez plus tester la logique sans mettre en place la couche Web, ce qui rend les tests lents et fragiles. Et lorsque vous voulez une deuxième interface - une CLI, une tâche cron - vous découvrez que la logique est piégée dans la première, et soit vous la dupliquez (vous avez maintenant deux copies à synchroniser, ce que vous ne ferez pas), soit vous effectuez une refactorisation délicate dans les délais. Les deux sont la taxe que vous payez pour avoir laissé la logique et son wrapper fusionner.

Il y a une raison plus profonde pour laquelle cela est particulièrement important pour le travail de l’IA. Ma CLI et mon interface utilisateur Web pilotent toutes deux les mêmes exécutions d'agent, et j'ai besoin qu'elles se comportent de manière identique - une exécution que je lance depuis le terminal pour déboguer ferait mieux de faire exactement ce que l'exécution d'un client déclenche à partir de l'interface utilisateur, ou je débogue un système différent de celui qui échoue. La logique partagée le garantit. Deux points d'entrée, un cerveau, signifient que le terminal et le navigateur sont des fenêtres sur la même machine, et non deux machines qui se ressemblent.

Donc : gardez la logique pure et sans cadre, et faites de chaque interface un traducteur léger. Cela coûte un peu de discipline au départ - la tentation de simplement le gérer dans le gestionnaire est réelle - et cela est récompensé à chaque fois que vous ajoutez une audience, écrivez un test ou déboguez une exécution à partir d'une porte différente de celle derrière laquelle elle s'est cassée.

Le frontend stupide

Je veux que mon interface soit aussi stupide que possible, et je dis cela comme le plus grand compliment. Moins il en sait, moins il peut y avoir de fuites, moins il peut y avoir de problèmes à l'endroit sur lequel j'ai le moins de contrôle : le navigateur de l'utilisateur, que je ne possède pas, auquel je ne peux pas faire confiance et dans lequel je ne peux pas garder de secret.

La règle est simple à énoncer : le frontend n’a aucun secret et ne prend aucune décision importante. Aucune clé API n'y réside. Aucune orchestration ne s’y produit. Aucune règle commerciale importante n’est appliquée par celui-ci. Son travail consiste à restituer ce qui lui est donné et à relayer ce que fait l'utilisateur – une vitre entre la personne et le système, et non un participant à la logique du système. Tout ce qui nécessite de la confiance se produit de l'autre côté d'un point de terminaison, sur le matériel que je contrôle, derrière l'authentification que j'applique.

La raison en est que le navigateur est fondamentalement un environnement peu fiable, et prétendre le contraire est la façon dont les gens sont blessés. Tout ce qui lui est envoyé peut être lu : chaque clé, chaque champ caché, chaque élément de logique « protégé » est visible par quiconque ouvre les outils de développement. La question de sécurité n’est donc pas « comment cacher ce secret dans le frontend », car vous ne pouvez pas ; la question est "comment puis-je m'assurer que le secret n'est jamais du tout dans le frontend." Une clé qui atteint le navigateur est une clé que vous devez considérer comme ayant déjà été divulguée, et concevoir autour de cette réalité plutôt que contre elle est tout le jeu.

Cela se connecte directement à l'échelle du chapitre 11. La raison pour laquelle le réseau d'artefacts ne peut pas effectuer de travail client n'est pas lié aux performances - c'est qu'un artefact parlant directement à un modèle n'a d'autre endroit que le navigateur pour conserver ses informations d'identification, ce qui, pour tout ce qui est réel, est disqualifiant. Grimper au niveau du serveur sans serveur revient, en grande partie, à donner les secrets dans un endroit sûr où vivre : une fonction côté serveur détient la clé, le navigateur appelle la fonction et la clé ne traverse jamais le fil jusqu'au client. Les barreaux de l’échelle sont, d’une certaine manière, des réponses de plus en plus bonnes à la question « où se trouvent les secrets ? ».

Il y a un avantage de conception à l'interface stupide au-delà de la sécurité, à savoir qu'une interface qui ne fait que restituer et relayer est considérablement plus simple à raisonner. Lorsqu'aucune logique importante ne réside chez le client, vous n'avez jamais à vous demander si le client et le serveur ne sont pas d'accord sur une règle, car un seul d'entre eux a une opinion. Les insectes ont moins d’endroits où se cacher. Le client est une vue ; le serveur est la vérité ; et la vérité vit exactement au même endroit.

Je construis donc des frontends magnifiques, réactifs et profondément ignorants. Ils savent comment montrer les choses et comment demander au serveur de faire les choses. Ils ne savent rien qui vaille la peine d’être volé et ne décident de rien qui mérite de se tromper. Poussez chaque secret et chaque décision réelle à travers le point final, sur le terrain que vous contrôlez. Gardez le verre propre et muet.

Le streaming est l'interface

La différence entre un produit d'IA qui semble vivant et un autre qui semble brisé n'est souvent pas le modèle : il s'agit de savoir si la réponse arrive d'un seul coup après un long silence, ou s'écoule jeton par jeton pendant que vous regardez. Le streaming n'est pas une optimisation des performances. C'est l'interface. Et une fois que j’ai compris cela, cela a changé la façon dont j’ai architecturé toute la moitié arrière de mes systèmes.

La forme naïve est celle de la requête-réponse : le navigateur demande, le serveur réfléchit pendant trente secondes, le navigateur obtient une réponse. Pour une requête rapide, c'est très bien. Pour un agent qui raisonne pendant une minute, ou exécute un build, ou effectue plusieurs étapes, c'est la mort : trente secondes d'un spinner ne se distinguent pas de trente secondes d'un blocage, et le doigt de l'utilisateur se dirige déjà vers l'actualisation. Le problème n'est pas que c'est lent. Le problème est que c'est silent, et le silence se lit comme un échec, quelle que soit la qualité de la réponse finale.

La forme que j’atteins est donc un ruisseau. Le serveur maintient une connexion ouverte et transmet les événements au fur et à mesure qu'ils se produisent (un jeton, une étape terminée, un outil appelé, un résultat partiel) et le frontend les restitue à l'instant où ils atterrissent. Le travail prend exactement autant de temps qu’auparavant, mais l’expérience est transformée, car l’utilisateur le regarde se produire plutôt que d’attendre dans le noir. Les progrès que vous pouvez constater sont rapides ; les progrès que vous ne pouvez pas voir semblent brisés. Même durée, sensation opposée.

Sur le plan architectural, cela vous fait gravir les échelons, et cela vaut la peine d'être honnête. Maintenir une connexion ouverte et envoyer des événements incrémentiels est carrément une capacité de premier plan - c'est l'une des choses spécifiques qui justifient de quitter le serveur sans serveur sur une machine que vous contrôlez, car une fonction qui doit revenir rapidement ne peut pas rester là en streaming pendant une minute. Quand j'ai dit au chapitre 11 qu'on ne grimpe que lorsqu'une capacité vous y oblige, le streaming est l'une des forces les plus évidentes. L’expérience utilisateur l’exige, et la demande d’expérience se révèle être une demande d’architecture.

Le modèle qui le relie est que le même flux alimente chaque interface. Le serveur émet une séquence d'événements saisis, et peu importe qui écoute : mon terminal les affiche sous forme de lignes défilantes, l'interface utilisateur Web les affiche sous forme de flux d'activité en direct, et les deux regardent le flux identique. Il s'agit d'un test une fois, exposé deux fois, une couche au-dessus : un flux d'événements, plusieurs moteurs de rendu. Le cerveau émet des événements ; les interfaces décident simplement comment les dessiner.

La leçon que je donnerais à quiconque crée des produits agentiques : concevoir d'abord le flux d'événements, comme une chose de première classe, et non comme une réflexion après coup sur un système de requête-réponse qui s'est avéré défectueux. Décidez quels événements le système émet (démarrés, réfléchis, appelés par un outil, produits, terminés) et faites de chaque surface un moteur de rendu de ce flux. Obtenez le bon streaming et une latence médiocre se sent bien. Si vous vous trompez, quelle que soit la vitesse, le silence ne ressemblera pas à un blocage.

Itinéraire par coût, pas par fidélité

Toutes les tâches ne méritent pas le même modèle, et le moyen le plus rapide de réduire une marge est d'envoyer une classification triviale à votre modèle le plus cher simplement parce que c'est celui en qui vous avez confiance. La discipline qui résout ce problème est un routeur : une fine couche qui examine la tâche et sélectionne le modèle le moins cher qui peut réellement le faire. Le routage tenant compte des coûts est l'un des éléments les plus efficaces dans un système agent, et presque personne ne le construit assez tôt – ce n'est certainement pas mon cas.

La forme est une échelle de modèles, du bon marché au plus cher, et une règle de choix. Un modèle minuscule, rapide et bon marché gère l'énorme volume de travail facile : classification, extraction, décisions de routage, "est-ce un oui ou un non". Un modèle de niveau intermédiaire gère le raisonnement ordinaire. Le modèle volumineux, coûteux et lent est réservé aux problèmes véritablement difficiles qui en ont réellement besoin. Il s'avère que la plupart des tâches sont des tâches faciles qui revêtent le costume de tâches difficiles, et les envoyer toutes au top model, c'est comme prendre un taxi pour vérifier la boîte aux lettres - ça marche, et c'est absurde, et on ne remarque l'absurdité que lorsque la facture arrive.

La raison pour laquelle cela est plus important dans les systèmes d'IA que dans les logiciels classiques est que le coût d'un appel varie de plusieurs ordres de grandeur en fonction du modèle qui le dessert, et dans une boucle agentique, vous effectuez un nombre énorme d'appels. Une exécution par un seul agent peut effectuer des dizaines d'appels modèles, et si chacun d'eux passe au niveau supérieur, votre coût par exécution peut être dix ou vingt fois supérieur à ce qu'il devrait être - une différence qui est invisible sur un seul appel et catastrophique sur une flotte d'appels. Le routage est la différence entre un produit avec une marge et un produit qui perd de l'argent d'autant plus efficacement que de plus en plus de personnes l'utilisent.

L'abstraction qui rend le routage possible est la passerelle du chapitre 6 – le même instinct de découplage, qui porte désormais ses fruits exactement comme promis. Étant donné que tout communique avec les modèles via une seule couche plutôt que de coder en dur un modèle spécifique sur chaque site d'appel, je peux modifier les règles de routage en un seul endroit, ajouter un nouveau modèle en tant que nouveau réseau ou échanger un fournisseur sans toucher à la logique qui demandait « un modèle pour faire cela ». Le routeur réside à l'intérieur de la passerelle. Le découplage précoce est ce qui rend le routage possible plus tard ; un système criblé de noms de modèles codés en dur n’a aucune couture dans laquelle insérer un routeur.

Il y a une note de discipline, selon laquelle les règles de routage deviennent obsolètes à mesure que les modèles changent, et elles changent constamment. Un modèle qui était haut de gamme et cher au dernier trimestre pourrait être de niveau intermédiaire et bon marché maintenant ; un modèle moins cher aurait pu être suffisamment performant pour être promu dans un travail que vous aviez réservé à quelque chose de plus grand. La table de routage est donc un être vivant, revisité délibérément, et non réglé une seule fois et oublié. Traitez-le comme une configuration que vous possédez et réglez, et non comme une décision que vous prenez une seule fois.

Envoyez le travail facile aux modèles bon marché, le travail acharné aux modèles coûteux, passez par une seule couture et maintenez la table à jour. C'est l'essentiel du contrôle des coûts dans un système agent, et cela aggrave chaque appel.

Adaptateurs, ou comment changer d'avis plus tard

Au chapitre 5, j'ai dit que l'expédition rapide n'était sûre que lorsque l'inversion était bon marché, puis j'ai promis de vous montrer les trappes de secours. C’est le premier et le plus important : l’adaptateur. Un adaptateur est une forme fine et convenue située entre ce qui veut des données et ce qui les fournit, de sorte que le fournisseur puisse être échangé sans que le consommateur ne s'en aperçoive. C'est le mécanisme qui transforme une décision irréversible en décision réversible.

Voici la version concrète, car l'abstraction obscurcit la simplicité. Supposons que j'ai besoin de données sur les best-sellers. Je définis une interface — une forme de fonction, fetchBestsellers(), qui renvoie une structure connue. Tout en amont dépend uniquement de cette forme, pas de la provenance des données. Ensuite, j'écris une implémentation derrière cela : peut-être une source eBay, car c'est celle que je peux défendre aujourd'hui. Plus tard, lorsque je veux une source différente, j'écris une deuxième implémentation de la même forme et j'échange celle qui est connectée. Rien en amont ne change. Le consommateur a demandé des best-sellers et les a obtenus ; il n'a jamais su et ne s'est jamais soucié du fait que le fournisseur avait changé en dessous.

La discipline consiste à dessiner l'interface au point d'incertitude – exactement aux décisions que vous pensez revoir. Vous n’emballez pas tout avec un adaptateur ; c'est de la sur-ingénierie, et cela enterre le code dans une direction indirecte dont personne n'a besoin. Vous enveloppez les articulations spécifiques où vous pouvez sentir l'avenir changer : la source de données que vous avez choisie sous la pression du temps, le fournisseur modèle avec lequel vous n'êtes pas marié, le processeur de paiement que vous avez choisi parce qu'un client l'a déjà utilisé. Partout où vous avez fait un choix avec un haussement d'épaules et un "ça fera l'affaire pour l'instant", installez-y un adaptateur, car "pour l'instant" est une promesse à votre futur moi que le changement sera bon marché.

La raison pour laquelle cela est si important pour le travail sur l’IA est que le sol bouge constamment. Le meilleur modèle pour un emploi change tous les quelques mois. Un fournisseur de données modifie ses conditions ou ses tarifs, ou ferme son API. Un outil sur lequel vous avez construit devient obsolète. Si votre système code en dur ces choix sur chaque site d'appel, chaque changement est une recherche et un remplacement dans l'ensemble de la base de code et une prière pour que vous les ayez tous capturés. S'ils se trouvent derrière des adaptateurs, chaque modification constitue une nouvelle implémentation d'une forme connue et un échange sur une seule ligne. Le taux de changement dans ce domaine est précisément la raison pour laquelle l'adaptateur gagne sa place ici plus rapidement que presque partout ailleurs.

Il y a aussi un avantage en matière de test, à savoir qu'un adaptateur vous offre un endroit naturel pour insérer un faux. Étant donné que le consommateur ne dépend que de la forme, je peux lui confier une implémentation stub qui renvoie des données prédéfinies, et je peux désormais tout tester en amont sans toucher du tout au fournisseur réel : pas d'appels d'API en direct, pas de limites de débit, pas de fragilité. La couture que j'ai construite pour échanger des fournisseurs s'avère être la même couture dont j'ai besoin pour les tests. Les trappes de secours ont tendance à être polyvalentes.

Dessinez l'interface là où vous n'êtes pas sûr. Écrivez une implémentation réelle et une fausse. Échangez librement. C'est ainsi que vous conservez le droit de changer d'avis.

Le commutateur simulation/live

La deuxième trappe de secours est un drapeau unique qui décide si le système fonctionne pour de vrai ou simplement pour faire semblant, et bien faire les choses est ce qui me permet d'expédier une coque fonctionnelle bien avant que le moteur derrière elle n'existe. C'est l'expression mécanique de l'instinct « ne polissez pas les moqueries » du chapitre 5, et il mérite son propre chapitre car la façon dont vous le construisez détermine s'il vous aide ou s'il pourrit tranquillement votre base de code.

La mauvaise façon - la façon dont je l'ai fait en premier - est de disperser les conditions dans le code : si vous vous moquez, faites ceci, sinon faites cela, répétées à chaque endroit où le comportement diffère. Cela fonctionne pendant environ une semaine, puis devient un cauchemar, car les chemins simulés et réels s'écartent. Chaque nouvelle fonctionnalité doit être construite deux fois, une fois pour chaque branche, et inévitablement une branche obtient un correctif, l'autre non, et maintenant votre simulation se comporte différemment de votre système réel d'une manière que vous ne pouvez pas voir jusqu'à ce qu'une démo se passe mal. Les conditions éparses expliquent comment le mode simulé devient un deuxième produit subtilement cassé que vous maintenez par accident.

La bonne manière utilise l’adaptateur du dernier chapitre. Mock versus live n'est pas une condition répandue partout - c'est un choix fait une fois, au démarrage, quant à l'implémentation à connecter derrière l'interface. Il existe un adaptateur fictif qui renvoie des données prédéfinies et un adaptateur actif qui fait la vraie chose, ils satisfont à la forme identique et un seul indicateur décide lequel est branché. Le reste du système n'a aucune idée à qui il parle et ne contient pas une seule condition liée à la simulation. Le commutateur vit exactement au même endroit, et tout ce qui se trouve en aval est parfaitement ignorant.

Le résultat est que je peux créer et expédier l'intégralité de l'expérience par rapport à la simulation, la présenter à un client, recueillir les réactions et affiner la forme, tout cela avant que la véritable intégration n'existe. Le front-end est réel. Le flux est réel. Les interactions sont réelles. Seules les données derrière la couture sont conservées, et comme la couture est propre, le remplacement ultérieur par des données réelles est un échange, pas une reconstruction. J'ai expédié des choses tout à fait convaincantes et entièrement moquées, et le jour où l'adaptateur live a atterri, rien n'a changé en amont. C'est le commutateur qui fonctionne comme prévu.

Il y a une exigence d'honnêteté qui va de pair avec cela, et je la tiens fermement : quand quelque chose est moqué, il doit être visiblement et indéniablement moqué par quiconque le regarde. Un badge, une étiquette, une bannière — quelque chose qui rend impossible de manquer « ces données ne sont pas encore réelles ». Le commutateur simulation/live est un outil pour construire rapidement, pas un outil pour tromper les gens sur ce qui est réel. Au moment où une simulation est confondue avec du live – par un client, par un coéquipier, par moi en trois semaines – cela cesse d'être une échappatoire et commence à être un mensonge. Marquez-le clairement et le commutateur reste honnête.

Un drapeau, une décision de câblage, un badge visible. Il s'agit d'un commutateur simulation/live qui vous accélère au lieu de vous empoisonner lentement.

Laisser une trace

La troisième issue de secours ne consiste pas à changer d'avis, il s'agit de pouvoir faire confiance à un travail que vous n'avez pas vu se produire. Lorsqu’un processus se déroule sans surveillance, la seule chose qui vous sépare d’une foi aveugle est la trace qu’il laisse derrière lui. Une exécution qui réussit silencieusement et une exécution qui échoue silencieusement semblent identiques de l'extérieur, et cette ambiguïté est intolérable dans un système que vous avez délibérément cessé de superviser. Ainsi, chaque exécution significative doit émettre des preuves structurées de ce qu’elle a fait.

Par structuré, j'entends plus qu'un mur de rondins. Les journaux servent au débogage lorsque quelque chose ne va pas ; une trace sert à confirmer que tout s'est bien passé sans avoir à lire quoi que ce soit. Une bonne trace est constituée par les artefacts eux-mêmes et leur manifeste : les fichiers produits, avec leurs chemins. Les liens générés. Un bref résumé en langage simple de ce qui s’est passé. Assez pour que je puisse jeter un coup d'œil au résultat d'une exécution nocturne et savoir, en quelques secondes et en toute confiance, si elle a fait ce que j'ai demandé - sans le déduire, sans l'espérer, le savoir.

Cela ferme une boucle ouverte par le chapitre 9, où j'ai défini « terminé » comme incluant une trace lisible. Voici le mécanisme derrière cette définition. La raison pour laquelle une trace est nécessaire est qu'un système sans surveillance vous oblige à le superviser - si vous ne pouvez pas dire à partir du résultat s'il a fonctionné, vous devez le regarder fonctionner, et maintenant vous avez perdu tout le bénéfice de l'exécution sans surveillance. La trace est ce qui rachète votre absence. C'est ce qui permet à l'équipe de nuit de fonctionner pendant la nuit, car cela signifie que le matin, vous pouvez vérifier le travail de nuit sans y être allé.

Il y a un principe de conception derrière cela qui se généralise bien au-delà de l’IA : un processus doit rendre lisible son propre succès ou son échec. Ne construisez pas des choses qui vous obligent à faire de la spéléologie pour découvrir ce qu'ils ont fait. Construisez des choses qui vous disent. La trace n'est pas un module complémentaire que vous utilisez lorsque le débogage devient pénible ; c'est un résultat de première classe de l'exécution, autant un livrable que l'objet de l'exécution. Lorsque je conçois une compétence ou une automatisation maintenant, « qu'est-ce que cela émet pour que je puisse lui faire confiance plus tard » fait partie de la spécification dès le départ, et non une réflexion après coup.

Le lien avec la fusion du matin du chapitre 10 est direct et mérite d'être explicité. La fusion – mon examen matinal impitoyable de la sortie nocturne – n’est possible que parce que la sortie arrive sous forme de traces lisibles. Je ne peux pas juger dix constructions du jour au lendemain si juger chacune d'entre elles signifie reconstruire ce qu'elle a fait à partir de preuves éparses. Je peux les juger rapidement si chacun me remet un résumé clair et ses artefacts présentés. La trace est ce qui rend la fusion assez rapide pour être effectuée chaque matin, ce qui rend l'ensemble de la boucle du jour au lendemain plus fusion durable plutôt qu'ambitieuse.

Émettez des preuves en tant que résultat de première classe. Rendre le succès et l’échec lisibles en un coup d’œil. Une course que vous ne pouvez pas vérifier à partir de sa trace est une course que vous finirez par garder - et le baby-sitting est la chose à laquelle tout cela était censé mettre fin.

Sachez combien coûte chaque course

La quatrième trappe de secours protège une chose différente : non pas votre capacité à changer d'avis ou à faire confiance à une course, mais votre marge. Dans un système agentique, les coûts sont réels, variables et invisibles, à moins que vous ne les rendiez délibérément visibles. Vous créez donc un grand livre qui enregistre le coût de chaque exécution, le moment où cela le coûte, ou vous vous lancez à l'aveugle dans une entreprise qui pourrait perdre de l'argent sur chaque client à votre insu.

Le piège est spécifique à la façon dont ces systèmes facturent, et il m’a pris au dépourvu. Différents types d'utilisation proviennent de différents pools à des tarifs différents : un appel interactif et un appel automatisé sans tête peuvent être facturés de manière complètement séparée, sur des compteurs différents, à des prix différents. Si votre comptabilité suppose que toutes les utilisations sont les mêmes, vos chiffres sont légèrement faux, et ils se trompent dans la direction la plus dangereuse : ils semblent corrects jusqu'à ce que la facture arrive et révèle que la flotte automatisée dont vous étiez si fier a puisé dans un pool que vous ne suiviez pas, à un rythme que vous n'avez pas modélisé. J'ai appris cela une semaine avant qu'un changement de facturation ne rende l'écart réel, ce qui est la seule raison pour laquelle il s'agit d'une leçon dans un livre plutôt que d'un trou dans mes comptes.

Le grand livre doit donc tenir compte des coûts dans la manière dont la facturation est réellement structurée, et non dans la manière dont vous souhaiteriez qu'elle soit. Chaque exécution enregistre non seulement ce qui s'est produit, mais aussi le pool d'où il a été tiré et quel est le tarif de ce pool, de sorte que le coût qui lui est attribué est le coût réel, et non une moyenne qui dilue l'utilisation bon marché et coûteuse dans un faux milieu réconfortant. La carte tarifaire – quel pool coûte quoi – se trouve au même endroit, saisie par pool, et est consultée chaque fois que le coût d'une exécution est calculé. Lorsque les tarifs changent ou qu'un nouveau pool apparaît, vous mettez à jour la carte en un seul endroit et chaque exécution future est correctement évaluée.

La raison pour laquelle il s’agit d’une échappatoire et pas seulement d’une comptabilité, c’est qu’elle préserve votre capacité à prendre des décisions judicieuses dans un contexte économique en évolution. Si vous connaissez le véritable coût par course, vous pouvez décider du montant à facturer, des fonctionnalités qui valent la peine d'être calculées, si un client donné est rentable et si une flotte de nuit s'amortit d'elle-même. Sans cela, chacune de ces décisions n’est qu’une supposition, et les suppositions sur l’économie de l’unité se transforment en une entreprise qui augmente ses pertes. La visibilité des coûts est ce qui maintient ouverte la possibilité de prendre de bonnes décisions – et c’est exactement à cela que sert une trappe de secours.

La discipline consiste à constituer le grand livre le plus tôt possible, avant d'en avoir désespérément besoin, car le moment où vous en avez besoin est le moment où vous pouvez le moins vous permettre de le reconstruire à partir de conjectures historiques. Instrumentez le coût dès la première exécution réelle. Clé à la structure de facturation réelle. Gardez la carte des tarifs à jour, de la même manière que vous maintenez la table de routage à jour, car les deux dérivent pour la même raison : l'économie sous-jacente à votre déplacement. Sachez combien coûte chaque exécution, tel qu'elle le coûte, et la marge cesse d'être un mystère.

Lorsqu'un échelon est épuisé

La deuxième partie se termine là où elle a commencé, à l'échelle, mais en regardant vers le haut : comment savoir si vous avez dépassé l'échelon sur lequel vous vous trouvez et qu'il est vraiment temps de grimper ? Parce que la discipline du chapitre 11 – se placer sur l'échelon le plus bas qui fonctionne – a une discipline correspondante qui est tout aussi importante et plus facile à se tromper : reconnaître le moment honnête où l'échelon est épuisé, et ne pas confondre un simple inconfort avec ce moment.

Le signal est la capacité, pas la douleur. Vous grimpez lorsque l'échelon sur lequel vous vous trouvez structurellement ne peut pas faire quelque chose dont vous avez réellement besoin - pas lorsque cela est ennuyeux, pas lorsque le code devient gênant, pas lorsqu'un échelon supérieur semble plus impressionnant. Un code gênant sur un réseau suffisant est un problème de refactorisation, et la réponse est de refactoriser, pas de grimper ; grimper pour échapper à un désordre ne fait que déplacer le désordre dans un endroit plus coûteux à entretenir. Le barreau n'est véritablement épuisé que lorsque vous pouvez pointer vers une capacité spécifique (diffusion en continu pendant des minutes, génération de sous-processus, maintien d'un état de longue durée que la plate-forme ne conservera pas) que ce barreau n'a pas et que le suivant a.

J'ai fait le mauvais choix dans les deux sens, et les deux me font mal. J'ai grimpé trop tôt, séduit par le sentiment qu'un véritable backend était plus sérieux qu'une fonction sans serveur, et j'ai payé pour cela un poids opérationnel dont je n'avais pas besoin - une machine pour sécuriser, surveiller et réveiller, le tout pour exécuter quelque chose que l'échelon inférieur aurait géré pendant mon sommeil. Et je suis resté trop longtemps, contorsionnant un barreau pour simuler une capacité qu'il n'avait pas, empilant des solutions de contournement sur des solutions de contournement jusqu'à ce que la contorsion coûte plus cher que la montée n'aurait eu lieu. La compétence consiste à les distinguer : est-ce un gâchis que je devrais nettoyer, ou un plafond que j'ai réellement touché ?

Le fait qu'il s'agisse d'un véritable plafond est que les solutions de contournement cessent d'être laides et commencent à être fragiles. Un code laid mais solide sur le barreau de droite est bien – ce n'est tout simplement pas joli, et joli est peu coûteux à différer. Mais lorsque vos solutions de contournement commencent à échouer d'une manière que vous ne pouvez pas totalement contrôler, lorsque vous combattez la nature fondamentale de la plate-forme plutôt que seulement ses aspérités, lorsque la chose dont vous avez besoin est quelque chose pour laquelle l'échelon n'a jamais été conçu - ce n'est pas un gâchis, c'est un plafond, et le geste honnête est de grimper. C’est la fragilité, et non la laideur, qui est le signal.

And when you do climb, the escape hatches from this whole part are what make it survivable. Because the logic lives in a framework-free service layer, moving it to a new rung is re-wrapping, not rewriting. Because providers sit behind adapters, the new environment inherits the same swappable seams. Because runs leave traces and costs are ledgered, you can tell whether the climb actually helped. The disciplines that kept you disciplined on the low rung are exactly what make the climb cheap when it's finally justified. C'est toute l'échelle de l'architecture : commencez bas, construisez les écoutilles et ne grimpez que lorsqu'un véritable plafond – ni votre ego, ni un gâchis – ne vous laisse aucun choix honnête.

Un agent derrière un serveur

La deuxième partie s'est terminée au sommet de l'échelle. La troisième partie va à l'intérieur, car l'échelon supérieur est l'endroit où se trouve la chose la plus intéressante et la plus incomprise que je construis : un agent fonctionnant sans tête, derrière un serveur, effectuant un travail que personne ne regarde en temps réel. C'est la salle des machines de tout, et cela vaut la peine de ralentir pour expliquer ce que signifie réellement « sans tête » et pourquoi cela change la forme de ce que vous pouvez construire.

Un agent sans tête est un agent sans humain assis devant lui. Il n'y a pas de fenêtre de discussion dans laquelle il tape, personne ne lit sa sortie au fur et à mesure et ne la pousse. Au lieu de cela, il est invoqué par un programme : mon serveur l'appelle, lui confie une tâche et le laisse fonctionner. La même fonctionnalité sous-jacente qui alimente un assistant interactif est désormais un sous-programme dans un système plus vaste, appelé de la même manière que n'importe quelle autre fonction, sauf que cette fonction peut raisonner, utiliser des outils et produire de véritables artefacts. Ce recadrage – du partenaire de conversation à la capacité appelable – est tout le déverrouillage.

La raison pour laquelle cela est important est qu'un humain dans la boucle est un goulot d'étranglement, et la première partie visait entièrement à supprimer les goulots d'étranglement qui n'ont pas besoin d'être là. Un agent interactif ne peut travailler qu'aussi vite qu'une personne peut lire et répondre. Un agent sans tête n'a pas de telle limite : il peut s'exécuter à trois heures du matin, en exécuter dix en parallèle, s'exécuter selon un calendrier, s'exécuter en réponse à un événement. Dès que l'agent cesse d'avoir besoin d'une surveillance humaine, il devient quelque chose que vous pouvez composer en systèmes, et la composition est l'endroit où l'effet de levier se compose. Un agent à qui vous parlez est un outil. Une centaine d’agents que vous orchestrez, c’est une usine.

La forme architecturale est celle du chapitre 12, maintenant avec un agent comme chose enveloppée. Il y a un serveur – l'échelon supérieur – et à l'intérieur, l'agent est invoqué dans le cadre de l'exécution d'une requête. Un utilisateur déclenche une exécution via l'interface stupide ; la requête traverse le point de terminaison jusqu'au serveur ; le serveur appelle l'agent sans tête ; l'agent travaille, produit et les résultats reviennent. L'agent est le cerveau, le serveur est le corps qui le porte et le frontend est le visage. Même anatomie qu’avant, avec un organe bien plus performant au milieu.

Ce qui rend cela réellement différent du travail de serveur ordinaire - et ce dont parle réellement le reste de la partie III - est qu'une exécution d'agent est longue, en continu, avec état et parfois coûteuse, contrairement à un appel de fonction normal. Il ne revient pas en millisecondes ; il réfléchit un moment. Cela ne produit pas une seule réponse ; il émet une séquence d'étapes. Cela ne fonctionne pas de manière isolée ; il génère des outils et touche le monde extérieur. Chacune de ces propriétés brise l'hypothèse sur laquelle les serveurs de requêtes-réponses ordinaires sont construits, et chacune constitue un chapitre : le sous-processus, le flux, l'environnement dans lequel il s'exécute, le pool de coûts dont il s'inspire.

Voici donc la carte de la partie III. Nous avons placé l'agent derrière un serveur. Maintenant, nous découvrons ce que cela prend réellement.

Le modèle de sous-processus

La manière la plus directe d'exécuter un agent sans tête est également celle que les gens trouvent la plus surprenante : j'exécute le même outil de ligne de commande qu'un développeur utiliserait de manière interactive, sauf que mon serveur le génère en tant que sous-processus et lit sa sortie par programme. Il n’existe pas de « version serveur » distincte de l’agent. Il y a l'outil, et il y a mon serveur qui pilote l'outil comme le ferait un opérateur très rapide et très patient. Comprendre pourquoi cela fonctionne – et pourquoi c’est mieux que l’alternative évidente – mérite un chapitre.

L'alternative évidente est d'appeler directement l'API du modèle et de créer vous-même tout le comportement de l'agent : la boucle d'utilisation des outils, la gestion des fichiers, l'échafaudage de raisonnement, les nouvelles tentatives. Les gens optent pour cela parce que cela semble plus « approprié », plus proche d’une véritable ingénierie. Mais cela signifie reconstruire, puis maintenir, une énorme quantité de comportements que l'outil de ligne de commande implémente déjà et qui s'améliore à chaque mise à jour de l'outil. En créant l'outil en tant que sous-processus, j'hérite de tout cela gratuitement. Lorsque l'outil s'améliore dans l'utilisation des outils, mon système s'améliore dans l'utilisation des outils, et je n'ai rien fait. Je me tiens sur les épaules de l'outil plutôt que de réimplémenter ses jambes.

Le mécanisme est humble et robuste. Mon serveur lance l'outil en tant que processus enfant, lui transmet la tâche et l'outil renvoie une sortie structurée - pas de texte libre, mais une séquence d'événements lisible par machine décrivant ce qu'il fait. Mon serveur lit ce flux ligne par ligne, et chaque ligne est un événement sur lequel il peut agir : relayer vers le frontend, enregistrer dans une trace, calculer un coût, mettre à jour l'état. Le sous-processus est le moteur ; mon serveur est le harnais qui l'entoure, traduisant entre le monde de l'outil et le reste de mon système. C'est l'intégration la plus humble possible et, précisément pour cette raison, l'une des plus durables.

La propriété qui fait briller ce modèle est que la sortie structurée transforme un outil conversationnel en un outil programmable. Si l’outil n’émettait que de la prose, je serais obligé d’analyser l’anglais, qui est fragile et triste. Parce qu'il émet des événements structurés, je peux traiter l'agent comme un composant sage qui parle d'un protocole - et dès que quelque chose parle d'un protocole, vous pouvez construire de manière fiable dessus. La frontière du sous-processus, qui ressemble à une limitation, est en réalité la couture nette qui permet à deux systèmes évoluant indépendamment de coopérer : l'outil évolue de son côté, mon harnais évolue du mien, et le flux structuré est le contrat entre eux.

Il y a une note de discipline, selon laquelle la génération de sous-processus est carrément une capacité de premier plan – vous ne pouvez pas le faire aux échelons inférieurs, ce qui est l'une des raisons concrètes pour lesquelles la salle des machines vit là où elle se trouve. Une fonction sans serveur qui doit revenir en quelques secondes ne peut pas rester là à diriger un sous-processus qui réfléchit pendant une minute. Ainsi, le modèle de sous-processus et le backend personnalisé arrivent ensemble ; le besoin du premier est souvent ce qui justifie l’ascension vers le second.

Générez le véritable outil. Lisez son flux structuré. Soyez le harnais, pas la réimplémentation. Héritez gratuitement de chaque amélioration.

Le flux en pratique

Le chapitre 14 a soutenu que le streaming est l'interface. Ce chapitre traite de ce qu'il faut réellement faire pour transporter un flux depuis un sous-processus dans la salle des machines jusqu'aux pixels se déplaçant dans le navigateur de quelqu'un, car le principe est simple et la plomberie est l'endroit où les gens se détachent. Il y a trois sauts, et chacun peut laisser tomber le flux sur le sol si vous n'êtes pas délibéré.

Le premier saut est le sous-processus vers le serveur. L'outil émet ses événements structurés ligne par ligne sur sa sortie, et mon serveur les lit au fur et à mesure de leur arrivée - sans attendre la fin du processus pour tout lire en même temps, ce qui est l'erreur qui reconvertit silencieusement un système de streaming en un système de requête-réponse. Le but est de réagir à chaque événement dès son arrivée, de sorte que le serveur lit progressivement, analyse chaque ligne en un événement et en fasse immédiatement quelque chose. Si vous mettez en mémoire tampon ici, tout ce qui est en aval hérite du délai et vous avez perdu le flux dès le premier saut.

Le deuxième saut est le serveur du navigateur. Le serveur maintient une connexion de longue durée ouverte au frontend et transmet chaque événement à mesure qu'il le traite. C'est le saut qui exige l'échelon supérieur, car maintenir cette connexion ouverte pendant la durée d'une exécution d'une minute est précisément ce que les échelons inférieurs ne vous permettent pas de faire. Chaque événement provenant du sous-processus est transmis, remodelé pour les besoins du frontend et envoyé à la connexion ouverte dès qu'elle est prête. Côté serveur, il s'agit d'un relais : depuis le processus jusqu'au navigateur, avec le moins de latence possible entre les deux.

Le troisième saut est le rendu du navigateur. Le frontend reçoit chaque événement et met à jour la vue immédiatement : un jeton s'ajoute au texte, une étape s'allume dans le flux d'activité, un artefact produit apparaît. C'est là que toute la discipline en amont porte ses fruits ou non : si chaque saut précédent préserve le streaming et que le frontend s'affiche avec impatience, l'utilisateur regarde le travail se dérouler en direct. Si un saut est mis en mémoire tampon, l'utilisateur reçoit une rafale à la fin et se demande pourquoi il a attendu. L’expérience est aussi fluide que son moindre saut de streaming.

L'idée unificatrice, et ce que j'attacherais à tout le chapitre, est qu'un ruisseau est une chaîne et que chaque maillon doit la préserver. Il ne suffit pas que l'outil diffuse et que le frontend soit capable de diffuser ; chaque saut entre les deux doit transmettre les événements sans les accumuler. Un lien de mise en mémoire tampon n'importe où dans la chaîne détruit silencieusement tous les liens de streaming qui l'entourent, et l'échec est invisible lors de la révision du code - on dirait que cela fonctionne, il semble simplement cassé. Ainsi, lorsqu'un système qui devrait diffuser ne le fait pas, la question de débogage est toujours la même : quel lien accumule ?

Concevez toute la chaîne pour transmettre les événements avec impatience. Lisez progressivement, relayez immédiatement, effectuez un rendu avec impatience. Réalisez les trois sauts et la réflexion d'une minute de la salle des machines devient une minute de progrès visible, vivant et digne de confiance.

Le piège de l’environnement

Ceci est un chapitre sur une catégorie de bugs qui m'a humilié plus que n'importe quelle erreur logique : le bug d'environnement, où le code est parfait et le système fait toujours la mauvaise chose à cause de quelque chose dans l'environnement dans lequel il s'exécute et que vous ne pouvez pas voir en lisant le code. Dans le travail des agents sans tête, ces phénomènes sont particulièrement vicieux, car l'agent court là où vous ne regardez pas et l'environnement dont il hérite est invisible jusqu'à ce qu'il morde.

Le piège spécifique qui m'a le plus appris impliquait un titre d'identification assis dans l'environnement. Le comportement que j'ai obtenu dépendait entièrement de la présence ou non d'une variable d'environnement particulière lors de l'exécution de l'agent - et sa présence ou son absence ne modifiait pas une seule ligne de code, donc la lecture du code ne m'a rien dit. Avec la variable définie dans un sens, l'agent prélevait sur un compte et facturait dans un sens. D'une autre manière, il s'appuyait sur un compte entièrement différent, facturant différemment, avec des limites différentes. Même code, même commande, conséquences complètement différentes dans le monde réel, et la seule différence réside dans l'environnement invisible dans lequel le processus est né.

La raison pour laquelle cette classe de bugs est si dangereuse est qu'elle est silencieuse et contextuelle. Cela ne génère pas d'erreur : le système fonctionne, il fonctionne simplement mal, en utilisant la mauvaise ressource ou le mauvais compte. Et c'est contextuel, ce qui signifie qu'il peut fonctionner parfaitement dans l'environnement dans lequel vous l'avez testé et échouer dans l'environnement dans lequel il s'exécute réellement, car ces deux environnements diffèrent par une variable que vous n'avez jamais pensé à comparer. L'écart entre les « travaux sur ma machine » du chapitre 9 et les « travaux en production » est très souvent exactement celui-ci : une différence d'environnement ni évidente ni enregistrée.

La discipline qui me sauve est de traiter l'environnement comme une entrée explicite et inspectée à chaque exécution, et non comme des conditions ambiantes que j'espère bonnes. Avant une exécution sans tête, je veux savoir précisément de quel environnement il héritera : quelles variables sont définies, quelles informations d'identification sont couvertes, quel compte il facturera. L'hygiène de l'environnement n'est pas glamour, mais une variable parasite peut coûter de l'argent réel ou s'infiltrer sur le mauvais compte, et espérer n'est pas un contrôle. Faites de l’environnement quelque chose que vous affirmez et vérifiez, et non quelque chose que vous supposez.

Cela se connecte à la trace du chapitre 18 d'une manière que j'ai dû apprendre à mes dépens. Une bonne trace doit capturer en partie l’environnement pertinent dans lequel l’exécution est exécutée – pas les secrets eux-mêmes, évidemment, mais quel compte, quel mode, quelle configuration. Parce que lorsqu'une course sans tête fait quelque chose de surprenant, la première question est "dans quel environnement se trouvait-elle réellement", et si la trace n'enregistre pas cela, vous êtes réduit à deviner des conditions invisibles après coup. La trace d'une exécution doit rendre son environnement aussi lisible que sa sortie.

Traitez l'environnement comme une entrée, inspectez-le avant de lui faire confiance et enregistrez-le dans la trace. Il ne suffit pas d’avoir un code correct lorsque l’environnement dans lequel il s’exécute peut tranquillement faire en sorte que le bon code fasse la mauvaise chose.

La répartition du pool de crédit

Le dernier chapitre de cette première partie de la partie III porte sur une connaissance spécifique et durement acquise qui se généralise en une leçon plus large : la façon dont l'utilisation est facturée peut changer sous vos yeux, et si votre modèle mental de « comment suis-je facturé » est erroné, chaque décision en aval fondée sur celui-ci est également fausse. Mon éducation ici est venue de la découverte que les utilisations sans tête et interactives ne proviennent pas nécessairement du même endroit.

La situation était la suivante. J'avais supposé, raisonnablement mais à tort, que toute l'utilisation de mon agent était fongible – qu'une exécution était une exécution, facturée à partir d'un seul compartiment, à un tarif unique, quelle que soit la manière dont elle était invoquée. Ensuite, j'ai appris que l'utilisation sans tête, les exécutions pilotées par les sous-processus du chapitre 22, puisaient dans un pool mesuré distinct de celui de l'utilisation interactive, à son propre rythme, dans ses propres limites. Les deux types de travail que je considérais comme identiques étaient, à des fins de facturation, deux choses différentes s'appuyant sur deux comptes différents. Et ce n'était pas statique : un changement dans la façon dont fonctionnait la scission allait se produire, ce qui aurait creusé l'écart juste au moment où ma flotte de nuit s'appuyait le plus fort sur le pool sans tête.

La leçon immédiate est celle du chapitre 19, avec maintenant une cause concrète : votre comptabilité analytique doit modéliser la structure de facturation telle qu'elle est réellement, y compris les répartitions dont vous ignoriez l'existence. Si j'avais continué à chiffrer chaque exécution à un taux pondéré, mes chiffres auraient dérivé de la réalité précisément à mesure que j'évoluais vers le côté sans tête : plus je me penchais sur l'automatisation du jour au lendemain, plus mes coûts seraient devenus erronés, et je l'aurais découvert via une facture plutôt que par un grand livre. Connaître la répartition du pool est ce qui m'a permis de saisir correctement la carte des tarifs et de garder le grand livre honnête.

La leçon plus large est plus intéressante et plus durable, car les structures de facturation spécifiques continueront de changer et ce livre daterait instantanément s'il concernait une structure en particulier. La leçon à retenir est que les aspects économiques d’un système d’IA sont une cible mouvante entretenue par quelqu’un d’autre que vous, et que vous devez les suivre activement plutôt que de supposer que le modèle d’aujourd’hui tiendra demain. Changements de prix. Les pools se divisent et fusionnent. Les taux bougent. De nouveaux niveaux apparaissent. Rien de tout cela n’est sous votre contrôle, et tout cela dépend directement de la rentabilité de votre produit. Traitez le modèle de facturation comme externe, versionné et sujet à changement – ​​quelque chose que vous revérifiez délibérément, et non quelque chose que vous avez appris une fois et que vous pouvez désormais ignorer.

L’habitude que cela crée mérite d’être soulignée clairement. Lorsque l’économie d’utilisation est importante pour votre entreprise – et c’est toujours le cas dans un système agent – ​​assignez-vous la tâche permanente de comprendre la réalité de facturation actuelle, et non celle que vous avez internalisée lorsque vous avez commencé. J'ai surpris la scission du pool une semaine avant que cela ne fasse mal, et la seule raison pour laquelle je l'ai découvert était que j'avais commencé à traiter la facturation comme quelque chose à surveiller plutôt que de supposer. Cette semaine d’avertissement a fait la différence entre une leçon et une blessure.

Suivez l’économie comme si elle pouvait changer, parce qu’elle le peut, et elle le fera, et ce n’est pas à vous de la geler.

Le milieu manquant : reprise de la session

La propriété du travail d’agent de longue durée que j’ai mis le plus de temps à apprécier est qu’il est, en fait, de longue durée – et ce mot fait plus que décrire la durée, il redéfinit discrètement ce que signifie un échec. Dans le travail court, un échec met fin au travail ; dans un travail long, un échec ne devrait mettre fin qu'à l'étape en cours, et le travail continue. C'est une conception complètement différente.

La forme naïve traite une exécution comme atomique : soit elle réussit en tant qu’unité, soit elle échoue en tant qu’unité. Pour un appel API de 200 millisecondes, c'est très bien : personne ne se soucie de reprendre un appel qui allait revenir dans le temps nécessaire pour s'en apercevoir. Pour une analyse d'agent de 45 minutes, l'atomicité est catastrophique. Un redémarrage d'un serveur à la minute quarante jette trente-neuf minutes de réflexion, d'appels d'outils et d'artefacts produits, et si cela se produit avec une certaine régularité - ce qui est le cas dans les déploiements réels - l'ensemble de l'économie de la flotte s'effondre sous le poids d'un travail presque terminé.

Ce que vous voulez, c'est reprendre. Au redémarrage, l'agent regarde où il est arrivé, reconstruit l'état et continue à partir du dernier point de contrôle durable au lieu du début. Le mécanisme est ennuyeux : au fur et à mesure que l'exécution progresse, il écrit des marqueurs de progression dans un stockage durable – pas chaque jeton, mais chaque étape significative (un appel d'outil terminé, un artefact produit, un sous-objectif coché). Les marqueurs décrivent suffisamment bien l’état pour qu’un nouveau processus puisse reprendre le chemin sans avoir vécu ce qui précède. Pas cher à écrire, inestimable quand survient le crash.

La discipline choisit ce qui constitue une étape significative. Trop fin et vous écrivez plus de marqueurs que de progrès, faisant glisser la course et encombrant le magasin. Trop grossier et un crash entre les points de contrôle vous coûtera beaucoup de travail. La bonne granularité est « à peu près ce qu’un humain considérerait comme une étape » – les limites auxquelles, si vous deviez expliquer ce que fait l’agent en ce moment, vous modifieriez votre réponse. Ce sont les coutures ; ce sont les points de contrôle.

La reprise de session compose également avec la trace du chapitre 18 d'une manière plus propre qu'il n'y paraît. La trace enregistre déjà ce qui s'est passé, pour le bénéfice de l'humain ; l'état de reprise est ce qui s'est passé, sous une forme que la machine peut manger. Si la trace est bien structurée – et elle devrait l’être – vous n’avez pas besoin d’une couche de stockage distincte pour la reprise ; la trace elle-même fait également office de journal de point de contrôle. Un artefact structuré sert à la fois à la fusion matinale et à la récupération après crash, ce qui est exactement le genre de dividende que la conception épurée continue de rapporter.

Il existe un mode de défaillance subtil qui mérite d'être mentionné. Le CV n'est valable que dans la mesure où vous supposez que le monde n'a pas changé entre le crash et le redémarrage. Si le fichier d'entrée a été écrasé, le compte cible a été déplacé, le modèle est devenu obsolète - la reprise continuera volontiers dans un monde qui n'existe plus. Ainsi, une reprise de l'exécution devrait vérifier ses hypothèses avant de replonger, en vérifiant que les pièces dont elle dépendait auparavant sont toujours les pièces dont elle dépend maintenant. La reprise aveugle est la façon dont vous transformez un petit crash en un résultat subtilement erroné.

Supposons que chaque long parcours puisse être interrompu, écrivez des marqueurs bon marché à des étapes significatives, vérifiez avant de continuer. L’interruption coûte alors quelques secondes, et non des heures, et l’économie de la flotte commence à fonctionner.

Exécutions parallèles

Un agent sans tête est un outil. Une centaine d'entre eux fonctionnant simultanément, c'est une usine - c'était la punchline du chapitre 21, et ce chapitre est le chapitre sur ce qui change réellement lorsque vous franchissez cette ligne. Parce qu'une flotte de parcours parallèles n'est pas simplement « un parcours effectué plusieurs fois ». C'est un animal différent, avec ses propres modes d'échec, ses propres goulots d'étranglement et sa propre discipline.

La première chose qui doit changer, c’est l’isolement. Lorsque les exécutions partagent un répertoire de travail, un fichier temporaire partagé, un élément d'état partagé, elles se contaminent mutuellement d'une manière qui se manifeste par des échecs irréguliers et non reproductibles - le genre d'échecs dans lesquels vous réexécutez la même entrée et obtenez un résultat différent en fonction de ce qui se passait en même temps. Ainsi, chaque exécution parallèle dispose de son propre espace de travail, de ses propres informations d'identification étroitement définies, de son propre chemin de trace. Ils ne peuvent pas se marcher dessus parce qu’ils ne sont pas au même endroit. L’isolement n’est pas une bonne chose ; c'est ce qui rend le parallélisme observable.

La deuxième chose qui change, c’est le goulot d’étranglement. Naïvement, vous penseriez qu’une flotte d’une centaine d’exécutions est entravée par le calcul, et vous auriez tort. Dans un système agent, le goulot d'étranglement est presque toujours la limite de débit du modèle (le nombre de jetons par minute que votre fournisseur vous servira réellement) et, plus loin, votre propre budget d'attention pour examiner ce qui en ressort. Doubler la taille de la flotte alors que vous êtes déjà au taux plafond ne fait rien d'autre que d'augmenter le nombre de files d'attente. La taille de la flotte n’est donc pas choisie en fonction de l’ambition ; il est choisi parmi le plafond honnête au-dessus, qui est généralement beaucoup plus bas que ce que le calcul suggère.

La troisième chose est la coordination. Une centaine de courses indépendantes sont faciles ; une centaine d'exécutions où B dépend de la sortie de A est l'endroit où l'orchestration se transforme en un problème de graphique. Ma discipline est de garder autant d'exécutions que possible totalement indépendantes, car l'indépendance est à cela que sert le parallélisme. Lorsque les dépendances sont authentiques – B a vraiment besoin de la sortie structurée de A – je les exprime explicitement comme un bord de dépendance dans l'orchestrateur, et non comme un implicite « eh bien, B s'exécute plus tard, donc tout ira bien ». L'ordre implicite permet d'obtenir des résultats subtilement erronés lorsque l'orchestrateur modifie sa planification.

Il y a un mode d'échec qui m'a surpris la première fois. Lorsqu'une centaine d'exécutions échouent de la même manière en même temps (parce que le modèle traverse une mauvaise heure ou qu'une panne de fournisseur les affecte tous), la défaillance de la flotte ressemble à un événement systémique unique et non à une centaine de problèmes indépendants. Mais la logique de nouvelle tentative à chaque exécution ne le sait pas ; chacun réessayera, chacun échouera à nouveau, et maintenant vous avez amplifié le problème en un marteau contre un mur qui ne bougeait déjà pas. Une flotte a donc besoin d'un coupe-circuit au niveau de l'orchestrateur : si le taux de défaillance augmente, reculez sur l'ensemble de la flotte, et pas seulement par exécution.

La dernière chose qui mérite d'être dite est que les exécutions parallèles rendent la trace du chapitre 18 non négociable plutôt que agréable. Lorsqu’une exécution fait quelque chose de surprenant dans une flotte d’une centaine, vous ne pouvez pas réexécuter pour vous reproduire : l’état qui a produit la surprise a disparu. La seule preuve que vous aurez, c'est ce que cette race a écrit de son vivant. Les flottes convertissent « Je le déboguerai plus tard » en « la trace était la session de débogage », et ce recadrage est ce qui force la discipline à écrire de bonnes traces en premier lieu.

Donnez à chaque course sa propre salle. Dimensionnez la flotte en fonction du plafond tarifaire honnête, et non de votre ambition. Exprimez explicitement les dépendances. Coupe-circuit au niveau de la flotte. Et écrivez la trace comme si c'était la seule preuve que vous aurez jamais, car lorsque la flotte se déplace, c'est généralement le cas.

La porte d'approbation

Tout ce qu’un système fait ne doit pas être autonome, et prétendre le contraire est la façon dont un logiciel confiant crée des erreurs coûteuses. Quelque part dans chaque pipeline significatif, il y a au moins un acte qu'un humain doit examiner avant qu'il ne se produise : un e-mail envoyé à un client, un déploiement qui touche la production, un paiement qui quitte un compte. La porte d'approbation est le mécanisme qui permet à la machine de faire tout le reste à pleine vitesse tout en s'arrêtant exactement à ces points.

La forme d'une porte est simple : l'agent produit l'action proposée, dans son intégralité, prête à être exécutée — mais ne l'exécute pas. Il attend qu'un humain dise oui ou non. L'approbation actionne l'interrupteur et l'action se déclenche ; le rejet le tue et la course indique pourquoi. Tout ce qui se trouve en aval de la porte est considéré comme « approuvé » comme déclencheur, et non comme « arrivé à la porte ». La porte est une pause dure, pas une suggestion, et le déclencheur est une intention humaine, pas un temps mort.

Où placer les portes est plus intéressant que comment en construire une. Ma règle est la suivante : exactement à la frontière où commence l’irréversibilité. À l’intérieur de la zone réversible, la machine fonctionne librement, se corrige, rejette les résultats, itère ; au moment où une action ne peut pas être annulée – parce qu’un message a été lu, de l’argent a été déplacé, une configuration s’est propagée – une porte se dresse. Les actions réversibles ne rapportent pas de portes ; l’irréversibilité le fait. Le placement des portes est en réalité un audit de réversibilité déguisé.

Le mode de défaillance le plus courant est le sur-gating. Quand trop de choses insignifiantes demandent l’approbation, les humains s’entraînent à cliquer oui sans lire, car le volume oblige à survoler. Désormais, la porte est un théâtre – nominalement présente, effectivement contournée – et la seule fois où l’approbation comptait réellement, c’est la seule fois où personne n’a regardé. Le sous-contrôle est le problème inverse : ignorer l’approbation de quelque chose qui s’est avéré irréversible et ne le découvrir qu’après les dommages. Les deux erreurs tuent la valeur du portail, et elles s'aggravent les unes avec les autres, car la réponse à une approbation manquée est souvent d'ajouter d'autres portails ailleurs, ce qui fait augmenter le taux d'écrémage.

La solution réside dans la conception : gardez les portes rares et significatives. Si une catégorie d’action nécessite à chaque fois une approbation, demandez-vous si elle est vraiment irréversible ou simplement intimidante – souvent « irréversible » est une habitude, pas un fait, et la porte peut être abandonnée. A l'inverse, lorsqu'un portail existe, rendez-le impossible à contourner en pratique : l'état par défaut est bloqué, pas de délai d'attente, pas d'approbation automatique, pas d'intelligent "vous n'avez pas répondu en cinq minutes donc nous avons supposé que oui". Un oui présumé n’est pas un consentement, et un système qui le traite comme tel n’est plus sûr.

Des portes bien placées présentent un avantage subtil auquel je ne m'attendais pas la première fois que j'en ai construit une. Parce que la porte oblige l'agent à préparer pleinement l'action avant d'attendre, l'artefact que les humains examinent est bien plus concret que tout ce qu'ils verraient en plein vol. Vous examinez un e-mail entièrement rédigé, pas un projet d'en rédiger un ; une différence de déploiement spécifique, pas une description de ce qui sera modifié. Le concret aiguise la décision oui ou non, qui aiguise la porte elle-même. La préparation avant la pause est ce qui rend la pause productive.

Placer les portes uniquement en cas d'irréversibilité. Préparez pleinement l’action avant d’attendre. Ne jamais approuver automatiquement, ne jamais expirer pour oui. Gardez-les rares, afin que lorsqu'un humain en voit un, il le regarde réellement.

Gestion des échecs & Nouvelles tentatives

Le dernier chapitre opérationnel porte sur l’échec – plus précisément sur l’erreur que j’ai commise pendant longtemps en traitant tous les échecs de la même manière. Dans un système agent, ils ne sont pas les mêmes, et prétendre qu'ils le sont est la façon dont vous brûlez les coûts en réessayant quelque chose qui ne réussira jamais, quel que soit le nombre de fois que vous l'aurez essayé. La discipline est la classification : nommez la forme de l'échec avant de décider quoi faire.

Il y a trois formes qui méritent d’être distinguées, et chacune appelle une réponse différente. Le premier est passager : le réseau est tombé en panne, le fournisseur a eu le hoquet, le limiteur de débit a dit "pas pour l'instant". Rien dans la tâche n’était faux ; le monde a brièvement refusé de coopérer. La bonne réponse est de réessayer, idéalement avec un intervalle exponentiel afin que les tentatives n'accumulent pas la panne qu'elles attendent. Les pannes transitoires sont les pannes invisibles : celles qu'un système bien conçu absorbe sans que l'appelant ne se rende compte de l'existence d'un problème.

La deuxième forme est sémantique. L'appel a atteint le modèle, le modèle a pris en compte la tâche et quelque chose dans l'interaction a échoué : un refus, un argument d'outil mal formé, une sortie qui n'a pas pu être analysée. Il est peu probable que réessayer exactement la même requête soit utile, car le monde n'est pas le problème ; la demande ou l'état est. Ce qui aide, c'est une variante : une invite reformulée, un modèle différent, un plan de repli. Traiter les échecs sémantiques comme transitoires – simplement réessayer aveuglément – ​​est l'une des habitudes les plus coûteuses dans les systèmes agentiques, car vous dépensez de l'argent et du temps réels pour marteler une demande qui ne réussira jamais inchangée.

La troisième forme est terminale. Le mémoire était faux. Le fichier d'entrée n'existait pas. Les informations d'identification sont révoquées. Aucune nouvelle tentative, aucune variation intelligente ne permettra d’y parvenir, car le problème se situe en amont de l’exécution elle-même. La bonne réponse est d'abandonner bruyamment, d'en faire ressortir la raison et de laisser un humain corriger l'entrée. Les pannes de terminal devraient donner l'impression de se heurter à un mur - évidentes, immédiates, sans tentatives inutiles - car la valeur offerte par le système est qu'il ne s'attaque pas silencieusement à une entrée cassée pendant des heures avant de révéler qu'elle est cassée lors de la première vérification.

Le mécanisme qui rend la classification possible est constitué par les signaux d’erreur typés. Si vos erreurs sont toutes des chaînes – « quelque chose s’est mal passé » – vous ne pouvez pas les acheminer et chaque échec obtient la même boucle de secours. Si vos erreurs comportent des balises structurées – kind (transient/sémantique/terminal), retry-hint, backoff-hint – le gestionnaire peut examiner la balise et choisir la bonne réponse de manière déterministe. Les erreurs de frappe ressemblent à de la bureaucratie jusqu'à ce que vous ayez vu une boucle de nouvelle tentative coûter une centaine de dollars en brûlant une erreur sémantique qu'elle n'allait jamais résoudre.

Il existe un mode d'échec subtil qui se situe au-dessus des catégories individuelles, à savoir les tempêtes de nouvelles tentatives. Lorsque de nombreuses exécutions échouent sémantiquement ou terminalement en même temps (un mauvais modèle d'invite poussé en production, un adaptateur cassé) la logique de nouvelle tentative locale de chaque exécution ne sait pas que la flotte est affectée, et chacune d'elles s'en prend. Le disjoncteur au niveau de la flotte du chapitre 27 est ce qui met fin à cela : lorsque le taux de défaillance de la flotte dépasse un seuil, arrêtez les tentatives sur l'ensemble de la flotte, et pas seulement par exécution. La contention individuelle n'aide pas ; la retenue doit être collective.

Classez avant de répondre. Réessayez uniquement de manière transitoire. Variez pour la sémantique. Abandonnez bruyamment pour le terminal. Et lorsque la flotte dans son ensemble tombe en panne, coupez le circuit au niveau de la flotte, car une centaine de courses restreintes constituent toujours une tempête.

L'orchestrateur

La partie III se termine au niveau situé au-dessus des exécutions individuelles – la couture où « un agent faisant une chose » se transforme en « une opération ». J'appelle cette couche l'orchestrateur, et c'est la partie mince et peu glamour de l'infrastructure qui décide ce qui s'exécute quand, dans quel ordre, au nom de qui et dans le cadre de quel budget. Bien faire les choses est ce qui transforme le modèle de sous-processus du chapitre 22 en une flotte que vous pouvez réellement exécuter.

L'orchestrateur gère trois états, et les maintenir proprement constitue l'essentiel de son travail. Premièrement, la file d’attente des travaux à effectuer – les travaux en attente d’un travailleur. Deuxièmement, le registre de ce qui se passe actuellement : quels travailleurs sont occupés à quels travaux et depuis quand. Troisièmement, l'historique de ce qui a été fait : les opérations terminées, leurs résultats, leurs traces, leurs coûts. Ensemble, ces trois états répondent à tout moment aux questions fondamentales de l'opérateur : qu'est-ce qui est en attente, qu'est-ce qui est en direct et que s'est-il passé. Répondez bien à ces trois questions et la majeure partie de la charge opérationnelle de la flotte s'évapore.

La tentation, lorsque vous en créez un pour la première fois, est de rendre l’orchestrateur intelligent. Demandez-lui de décider du modèle exact pour chaque tâche, de réécrire les invites, de réessayer avec des variations, de faire la classification des échecs du chapitre 29. Résistez. Le travail de l'orchestrateur consiste à planifier et à tenir les comptes, pas à réfléchir. Toutes les informations (routage, classification, tentatives) appartiennent aux exécutions, là où réside le contexte individuel ; l'orchestrateur est assis au-dessus et fait avancer le travail. Un orchestrateur mince sur des pistes riches est une conception qui dure ; un orchestrateur intelligent sur des exécutions stupides est un monolithe avec plus de modes de défaillance que l'une ou l'autre moitié.

La question de la dépendance est de savoir où les orchestrateurs deviennent véritablement utiles plutôt que simplement pratiques. Lorsque l'exécution B a besoin de la sortie de A, l'orchestrateur maintient l'avantage et refuse de planifier B avant la fin de A. Lorsque de nombreuses courses indépendantes peuvent avoir lieu en parallèle, l'orchestrateur les planifie simultanément en fonction du plafond tarifaire de la flotte. Si vous le construisez correctement, vous obtenez un petit moteur DAG qui respecte les dépendances et la capacité – exactement ce que fait un superviseur d'usine, traduit en logiciel.

Le lien avec l'argument du passage nocturne de la première partie est direct et mérite d'être mentionné, car c'est là que l'aspect technique rencontre l'aspect philosophique. Le travail de nuit n'est possible que parce qu'un orchestrateur peut gérer l'état de la flotte pendant que je dors : mettre en file d'attente le travail de ce soir, lancer chaque travail dès que la capacité s'ouvre, collecter les sorties et les traces, être prêt à remettre le matin la fusion d'une pile propre d'exécutions terminées avec leurs preuves jointes. Sans l'orchestrateur, "le laisser fonctionner du jour au lendemain" est un souhait. Avec lui, « laissez-le fonctionner du jour au lendemain » est une description de poste.

Il existe une discipline concernant ce que l'orchestrateur ne doit pas faire. Il ne doit pas contenir de logique métier. Il ne doit pas savoir à quoi ressemble une « bonne » course. Il ne devrait pas décider quand dépenser plus d’argent. Ces jugements appartiennent aux humains et aux races ; le travail de l'orchestrateur consiste à être fiable et stupide : planifier ce qui lui est dit, suivre ce qui lui est demandé et s'écarter. Chaque règle métier qui s'infiltre dans l'orchestrateur devient une règle difficile à modifier, car le planificateur est désormais couplé au domaine et le domaine se déplace plus rapidement que le planificateur ne le devrait jamais.

Nommez l’orchestrateur. Gardez-le mince. Donnez-lui trois états et aucune opinion. Laissez-le tenir la flotte pendant que vous dormez, et laissez la fusion du matin juger à votre réveil.

Grands livres qui se transforment en quelque chose

Le chapitre 19 explique pourquoi vous avez besoin d’un grand livre des coûts. Ce chapitre explique comment en construire un pour qu'il gagne sa place - car un grand livre mal conçu est pire que pas du tout, vous donnant la fausse confiance des chiffres sans la possibilité de répondre à de vraies questions à leur sujet.

La forme sur laquelle j'ai atterri est terne, ce qui est le type de forme correct pour un grand livre. Une ligne par exécution significative, horodatée, contenant chaque dimension qui pourrait avoir de l'importance plus tard dans sa propre colonne : quel pool, quel modèle, quel locataire, quel objectif, combien de jetons entrants, combien de jetons sortants, quel taux était en vigueur, quel était le coût résultant. Pas de résumés. Aucune agrégation. Pas de jolies étiquettes qui cachent les atomes sous-jacents. Le grand livre est la vérité brute ; tout le reste est une requête.

Le piège se rassemble trop tôt. Il est tentant, une fois le cycle terminé, d'augmenter le total mensuel d'un locataire et de passer à autre chose. Mais maintenant, le total est un résumé avec perte d’une réalité sous-jacente que vous ne détenez plus, et dès qu’une nouvelle question se pose – combien ont coûté les trajets automatisés de nuit sur l’ensemble de la flotte, par rapport aux trajets interactifs de jour – le résumé est inutile. Il n’a pas enregistré la dimension dont dépend la nouvelle question. Stockez les atomes et les agrégats au moment de la lecture ; le grand livre reste flexible face aux questions que vous n'avez pas encore pensé à poser.

L'autre piège consiste à donner du sens au nom d'une course. Si une exécution s'appelle « overnight-tenant-a-report-v2 » et que cette chaîne encode le locataire, le mode et l'objectif, vous ne pouvez pas l'interroger sans analyser le texte. Chaque dimension mérite sa propre chronique. L'analyse de texte de votre propre registre est une odeur qui indique que vous avez bronché face à la conception de schéma alors que vous auriez dû développer une colonne et passer à autre chose.

Il existe une discipline quant à ce qu'il faut inclure au-delà de l'évidence. Coût, jetons, locataire – bien sûr. Mais aussi : quelle version du modèle d'invite était en vigueur, quel modèle a été choisi, si l'exécution a réussi dès la première tentative ou après une nouvelle tentative. Ces dimensions semblent exagérées jusqu'au jour où une régression de modèle oblige la moitié de votre flotte à brûler des jetons, et vous devez répondre "quand cela a-t-il commencé et quel modèle est affecté". Cette réponse est triviale avec les dimensions enregistrées et impossible sans elles. Connectez-vous plus que ce dont vous pensez avoir besoin ; les disques sont bon marché et le regret coûte cher.

Le dernier principe est que le grand livre est uniquement en annexe. Vous ne réécrivez jamais une ligne ; si vous apprenez quelque chose plus tard – un taux était erroné, un objectif mal étiqueté – vous écrivez une ligne de correction qui fait référence à l’original. L'immuabilité signifie que le grand livre peut être fiable comme preuve, ce qui signifie qu'il peut étayer la conversation avec l'équipe financière d'un client lorsque la question sur la facture arrive. Un grand livre réécrit est un grand livre que personne ne peut défendre.

Des atomes, pas des résumés. Des colonnes et non des chaînes de noms. Plus de dimensions que vous ne le pensez. Ajout uniquement. C'est un grand livre qui s'aggrave ; rien de moins n’est un faux narrateur portant une feuille de calcul.

La ligne ToS

Chaque fournisseur de modèles dispose d'un document de conditions de service, et son nom honnête est "la liste des éléments qui entraîneront la fermeture de votre compte lorsque quelqu'un le regardera enfin". La plupart du temps, personne ne regarde. Parfois, quelqu'un regarde, et si vous avez fonctionné d'une manière techniquement interdite (grattage automatisé, utilisation agressive sans tête, introduction du modèle dans un service concurrent), l'application n'est pas graduelle. Les comptes ne sont pas prévenus. Ils se ferment.

La forme dangereuse du risque ToS est qu’il est asymétrique et retardé. Pendant longtemps, rien ne se passe ; le modèle qui viole les ToS fonctionne tout simplement, à moindre coût et en silence, et chaque jour de « travail encore » renforce la confiance qu'il continuera à fonctionner. Puis un jour, ce n’est pas le cas et les autorités arrivent sans prévenir. Il n’y a aucun gradient de conséquences auquel vous pouvez répondre : vous passez de la pleine capacité à zéro. Toute entreprise bâtie sur une violation des ToS est une entreprise avec un jour de silence restant, et le silence est tout le problème.

J'ai refusé un engagement client à ce sujet une fois, et cela s'est avéré être l'une des meilleures décisions commerciales que j'ai prises. La demande était de récupérer un grand site tiers, d'exécuter son contenu via un modèle et de republier des versions digérées. Techniquement réalisable en une après-midi ; commercialement attractif ; presque certainement contre les conditions de service de la source et celles du fournisseur de modèles. J'ai dit non, et le client a trouvé quelqu'un d'autre, et l'opération de quelqu'un d'autre a duré environ huit mois avant de s'arrêter. Pendant ce temps, mon compte fournisseur est toujours ouvert et le coût de la réputation d'être la personne qui a perdu le compte est un coût que je n'ai jamais payé.

La leçon n’est pas que les documents ToS sont sacrés. C’est qu’ils représentent une catégorie de risque dont le rayon d’explosion est asymétrique – un léger avantage en cas de franchissement de la ligne, un inconvénient catastrophique le jour où quelqu’un s’en aperçoit. Dans toute autre décision en matière de risque, vous pouvez pondérer l’ampleur multipliée par la probabilité. Ici, la probabilité d'une application sur une courte période est suffisamment faible pour paraître ignorée, mais l'ampleur le jour où elle atterrit est totale. Rare mais catastrophique n’est pas le genre de risque auquel on s’expose et qu’on voit ce qui se passe ; c'est le genre que vous contournez structurellement.

La discipline pratique est ennuyeuse : lisez les ToS. Ne parcourez pas, lisez. Pas une seule fois, le jour de votre inscription – périodiquement, car les conditions changent et le secteur évolue plus rapidement. Lorsque quelque chose dans les termes est ambigu, demandez et obtenez la réponse par écrit avant de passer à l'échelle. Quand quelque chose est clairement interdit, ne le faites pas, aussi attrayant que soit le client. Un client qui vous demande de violer les conditions d'un fournisseur est un client qui vous demande de supporter le risque qu'il ne veut pas supporter lui-même. Ce n'est pas un partenariat; c'est un déchargement.

L’avantage de la discipline est que le ToS devient une aide plutôt qu’une contrainte. Connaître la ligne signifie que vous pouvez y accéder en toute confiance, sans craindre une embuscade. Les gens qui contournent sur la pointe des pieds ce qu'ils pensent être interdit gaspillent autant d'énergie que ceux qui le traversent et s'inquiètent - une lecture honnête vous amène à un juste milieu entre agressif mais sûr. L’agression sur un terrain solide est la meilleure des formes.

Lisez les termes. Contourner les virages serrés. Dites non aux clients qui vous demandent de prendre leurs risques. Le compte que vous conservez est le compte qui vous permet de continuer à fonctionner.

Abonnement vs API

Deux façons de payer pour essentiellement la même capacité se côtoient sur les pages de tarification de la plupart des fournisseurs d'IA, et le choix entre elles n'est évident que lorsque vous êtes du mauvais côté. L'abonnement est un forfait mensuel avec un plafond souple sur le débit. L'API est par jeton, sans limite supérieure ni limite inférieure. Ni l’un ni l’autre n’est universellement moins cher, et l’erreur que je vois le plus souvent est de supposer que l’un d’entre eux l’est.

La forme de l'abonnement est prévisible et légèrement inefficace. Vous payez autant pour un mois lent que pour un mois chargé, ce qui signifie que la sous-utilisation subventionne la surutilisation. Si votre moyenne mensuelle se situe bien en dessous du plafond, vous laissez de l'argent sur la table en n'en utilisant pas davantage : le jeton marginal est effectivement gratuit jusqu'à ce que vous atteigniez la limite. Si votre moyenne se heurte au plafond, vous bénéficiez d'un taux agressif mais vous devez gérer un vrai plafond. L'abonnement est une bonne affaire lorsque votre utilisation est stable, prévisible et suffisamment élevée pour bénéficier du tarif forfaitaire.

La forme de l'API est imprévisible et précisément proportionnelle. Vous payez exactement ce que vous utilisez, sans plancher les jours calmes et sans plafond les jours bruyants. C'est formidable lorsque l'utilisation varie (une semaine de démonstration, une campagne client, un gros lot d'une nuit) car vous ne payez pas pour une capacité que vous ne consommez pas. C'est moche lorsqu'une boucle incontrôlée ou un agent mal formé brûle des jetons sans surveillance ; le compteur ne s'arrête pas à un plafond amical. L'API est une bonne affaire lorsque votre utilisation est pointue ou lorsque vous disposez de flux de travail qui bénéficient spécifiquement d'un fonctionnement sans tête et à parallélisme élevé que l'abonnement ne couvre pas.

Le point de croisement est l’endroit où cela cesse d’être de la philosophie et commence à être de l’arithmétique. Il existe un certain volume d'utilisation pour lequel le coût forfaitaire de l'abonnement est égal au coût par utilisation de l'API ; en dessous, l'API est moins chère, au-dessus, l'abonnement l'est. Ce chiffre est votre point de décision, et savoir où il se situe par rapport à votre charge de travail réelle fait la différence entre un choix intelligent et un choix à la mode. Modélisez votre utilisation – ne devinez pas. Prenez un mois réel, comptez les vrais jetons, calculez dans les deux sens. La réponse est souvent surprenante et change souvent à mesure que vous évoluez.

L'erreur que j'ai commise au début était de supposer que l'abonnement était destiné à un travail "sérieux" et que l'API était destinée à l'expérimentation, ce qui est à l'envers. L'abonnement récompense une charge prévisible et constante : des flux de travail matures avec un débit connu. L'API récompense les charges flexibles et pointues : un nouveau travail dont vous êtes encore en train d'apprendre la forme. Au contraire, la progression correcte est d'abord l'API, jusqu'à ce que vous connaissiez le modèle, puis l'abonnement une fois le modèle stable. S'engager sur un abonnement avant de connaître votre forme d'utilisation, c'est s'engager sur un coût plancher que vous n'avez pas gagné.

Il existe une position hybride qui mérite d’être mentionnée, à savoir que de nombreux praticiens dirigent délibérément les deux. Abonnement pour le côté interactif et humain dans la boucle où l'utilisation est mesurée par l'attention humaine et reste naturellement sous plafond. API pour la flotte sans tête où le pool séparé du chapitre 25 met de toute façon un compteur différent sous le travail. Utiliser les deux n’est pas un compromis ; il s'agit de faire correspondre la forme de paiement à la forme d'utilisation à chaque couche. Travail différent, mètre différent.

Modélisez l’utilisation. Croisez les chiffres avec les prix. Choisissez la forme qui vous convient et n'hésitez pas à exécuter les deux lorsque l'œuvre elle-même a deux formes.

Tarification d'un PoC

Le premier engagement rémunéré avec un nouveau client est une preuve de concept, et son prix est le chiffre le plus important de toute la relation, car il détermine tout ce qui suit. Sous-facturez et vous leur dites que le vrai travail devrait être tout aussi bon marché. Surchargez et ils n'achètent pas. Le bon numéro est celui qui filtre le sérieux des deux côtés sans exclure le client raisonnable.

Mon heuristique de travail est que le prix PoC doit être suffisamment élevé pour qu'un oui engage le client à réellement s'engager dans le résultat, et suffisamment bas pour qu'un non ne nécessite pas une salle de conférence pour l'expliquer. En pratique, pour moi, cela se situe dans une fourchette où le contrôle n'est pas une erreur d'arrondi mais n'est pas non plus une décision d'allocation de capital. S'ils disent oui, ils ont acheté du skin dans le jeu ; s'ils disent non, ils m'ont dit qu'ils ne sont pas prêts, et c'est l'information que je veux à la semaine zéro, pas au troisième mois.

Le mode de défaillance dans le bas de gamme est subtil. Lorsqu’un PoC est proposé à un prix suffisamment bas pour se sentir libre, le client ne le prend pas au sérieux. Ils ne rassemblent pas les contributions. Ils n'assistent pas aux examens. Le résultat arrive, ils le regardent, le classent sous « intéressant » et ne parviennent jamais au projet réel. Le faible prix n’a pas donné accès à une véritable conversation ; cela a permis au client de dire à moindre coût qu'il a exploré l'IA. Ce n'est pas ce que je vends, et c'est en fixant un prix en conséquence que j'arrête de le vendre.

Le mode de défaillance dans le haut de gamme est plus évident et moins dangereux. Vous citez haut, ils refusent, vous passez à autre chose. Le seul coût est le cycle de vente que vous avez investi, qui est réel mais récupérable. Des filtres de surtarification trop agressifs pour les clients ; des filtres de sous-tarification pour le mauvais type de client. Étant donné l’asymétrie des coûts, soyez élevé.

Il y a une question de portée qui va de pair avec le prix, et se tromper est de savoir comment les PoC dépassent le budget du côté du vendeur. La portée d'un PoC doit être suffisamment étroite pour être réalisée dans un laps de temps vraiment court (des jours et non des mois) et le livrable doit être un artefact spécifique et concret, et non une capacité générale. "Montrez-moi un prototype de l'assistant" est un champ d'application qui s'étend à jamais. « Rédiger cinq exemples de résultats pour ces cinq invites, dans ce format » est une portée qui se termine. La résiliation est ce qui rend le prix défendable ; tout ce qui n'a pas de limite dure dérive.

Une autre discipline : facturer le PoC comme un élément de campagne à part entière, et non comme un crédit pour un engagement futur. Lorsque le prix d'un PoC est intégré à une transaction future (« nous créditerons cela du projet réel »), le prix cesse d'être un nombre réel et devient un geste marketing, et le client cesse de le traiter comme tel. Un PoC est un produit autonome avec son propre prix et son propre critère de réussite ; le traiter comme une remise sur quelque chose de plus gros déprécie les deux. Si le client ne convertit pas, vous conservez les frais ; s’ils le font, vous facturez le projet réel selon ses mérites.

Évaluez le PoC comme un filtre et non comme une remise. Limitez la portée à quelque chose qui se termine. Présentez-le comme sa propre chose. Le bon numéro est celui qui fait apparaître les clients sérieux tout en gardant à l'écart ceux qui ne l'étaient pas.

Quand le débit de nuit est réellement payant

L’argument du quart de nuit de la première partie est magnifique en théorie. Ce chapitre est l'arithmétique qui décide quand c'est réellement vrai. Parce que l’automatisation a un coût de configuration fixe – rédiger le brief, surveiller la trace, renforcer le pipeline – et payer ce coût n’est payant que lorsqu’un flux de travail se répète suffisamment de fois pour l’amortir. En dessous de ce seuil, l’automatisation est une perte déguisée en progrès.

La forme est un calcul du seuil de rentabilité. Le coût de l'exécution manuelle d'une tâche correspond à votre taux horaire multiplié par le nombre d'heures par instance et par le nombre d'instances. Le coût de l’automatisation est une configuration unique importante, plus un petit coût marginal par exécution. Tracez les deux en fonction du nombre de fois que vous effectuerez la tâche : manuel est une ligne linéaire partant de zéro ; automatisé est un coût d'installation fixe plus une ligne peu profonde. Ils se croisent quelque part, et ce passage est votre point de décision. En dessous, faites-le à la main ; au-dessus, automatisez.

Le franchissement est généralement plus haut que ce que pensent les praticiens. Les coûts de configuration d'un pipeline de nuit véritablement fiable ne sont pas triviaux : vous rédigez le brief une seule fois, le renforcez contre les cas extrêmes, ajoutez des tentatives, câblez la trace, testez les modes de défaillance. Ces heures s'additionnent et le coût marginal par exécution n'est pas nul. Ma règle générale est qu'un flux de travail doit se répéter au moins cinq à dix fois avant de l'automatiser plutôt que de le faire manuellement, et le nombre exact dépend du coût de chaque exécution manuelle et de la fragilité de la version automatisée.

Le piège dans l’autre sens est la répétition manuelle héroïque. Lorsqu'une tâche se répète chaque semaine pendant un an – plus de cinquante fois – le calcul favorise fortement l'automatisation, et pourtant les praticiens continuent de l'exécuter à la main car « cela ne dure que quelques heures » à chaque fois. Ces quelques heures par semaine se transforment en une petite carrière consistant à faire la même chose encore et encore, et le coût est réel même si aucune instance individuelle ne semble coûteuse. Si vous effectuez le même type de travail plus de six fois environ, arrêtez-vous et évaluez correctement l'automatisation. L’instinct de continuer manuellement est généralement une aversion aux pertes déguisée en pragmatisme.

Il existe un deuxième coût de l’automatisation qu’il est facile de négliger : la maintenance continue. Les pipelines automatisés se brisent lorsque leurs entrées bougent, lorsque les modèles sont obsolètes, lorsque les adaptateurs se déplacent en dessous. Ainsi, le coût total du cycle de vie ne se résume pas uniquement à l’installation et à l’exécution ; il s'agit de la configuration plus par exécution plus une traînée de maintenance proportionnelle au nombre de pipelines que vous entretenez. Au-delà d’un certain point, l’ajout de pipelines fait que la facture de maintenance dépasse les économies réalisées. Automatisez ce qui est payant, retirez ce qui ne l'est pas et ne laissez pas la pile s'étendre au-delà de ce que vous pouvez entretenir.

La forme de flux de travail qui mérite le plus d’être automatisée est celle qui se répète selon un calendrier, a un brief clair et produit un artefact concret à chaque fois. Rapports hebdomadaires. Génération quotidienne. Rapprochements mensuels. C'est le point idéal : suffisamment récurrent pour que la configuration soit payante, suffisamment structuré pour que le brief reste complet et suffisamment observable pour qu'une trace vous indique que cela a fonctionné. Les travaux ponctuels, les travaux exploratoires et tout ce qui nécessite un jugement en direct ne sont pas de la bonne forme : ils appartiennent à la pile de pompons du chapitre 2, pas à la file d'attente du jour au lendemain.

Coûte honnêtement aux deux côtés. Automatisez au dessus du passage à niveau. Élaguez ce qui ne rapporte pas. Le débit nocturne est un levier, pas une règle : tirez-le là où les calculs le disent, et laissez-le tranquille là où les calculs disent que le pom manuel était moins cher.

Économie unitaire des jetons

La manière naïve de calculer le coût d’un run est de multiplier les jetons par le taux et d’appeler le produit le coût. Ce chiffre est toujours faux, et il est toujours faux dans la même direction : trop bas. Le coût réaliste par exécution est environ une fois et demie à deux fois supérieur au coût naïf, et l'écart provient d'un ensemble de coûts cachés qui n'apparaissent pas sur un seul appel d'API mais apparaissent systématiquement sur la facture.

Le premier coût caché concerne les nouvelles tentatives. Même un pipeline bien réglé retente un certain pourcentage de ses appels : échecs transitoires, délais d'attente, délais d'attente des limites de débit. Chaque nouvelle tentative rapporte de vrais jetons, et si le taux de nouvelle tentative est de cinq pour cent, alors votre coût effectif par exécution réussie est de un sur cinq pour cent de ce que dit le calcul naïf. Dix pour cent de tentatives, un à dix pour cent. Cela s'additionne plus rapidement que vous ne le pensez, et le taux de nouvelles tentatives est souvent plus élevé que vous ne le pensez, car il n'est mesuré que si vous le mesurez délibérément.

Le deuxième coût caché est le contexte. Every agent run loads a context — a prompt, examples, system instructions, prior conversation. Ces jetons comptent. Une brève question utilisateur qui coûte une centaine de jetons de sortie peut d'abord charger des milliers de jetons de contexte, et le côté entrée de ce ratio est facile à oublier lorsque vous regardez ce que coûte une exécution. Les contextes longs sont particulièrement coûteux car la plupart des fournisseurs facturent aussi bien les entrées que les sorties ; une invite système lourde est une taxe par exécution que vous payez à chaque fois.

Le troisième coût caché concerne les échecs de classification et les nouvelles invites dans la boucle d'un agent. Lorsque l’agent tente un appel d’outil qui échoue, réessaye avec un argument différent ou revient en arrière pour réfléchir à nouveau, chacune de ces étapes intérieures est constituée de jetons dépensés ne produisant aucun résultat directement utilisable. Un agent en dix étapes qui réussit proprement coûte moins cher qu’un agent en dix étapes qui réussit après deux retours en arrière, même si les deux produisent le même artefact final. Les détours internes sont invisibles pour le comte naïf et bien visibles sur l’addition.

Le quatrième concerne les frais généraux. Au départ, je ne les considérais pas du tout comme des coûts : les invites de préchauffage, les contrôles de santé, les évaluations, le petit trafic de maintenance généré par un système bien instrumenté. Individuellement triviaux, collectivement significatifs et systématiquement absents du calcul naïf car ils se produisent en dehors du flux principal. Si vos pipelines de surveillance sont sains, ils utilisent des jetons ; si vous ne comptez pas ces jetons, l'économie de votre unité est mauvaise.

La bonne réponse à tout cela est d’arrêter de mesurer au niveau des jetons et de mesurer au niveau de l’exécution. L'unité atomique de comptabilité analytique est une exécution terminée, et son coût réel correspond à tout ce que l'exécution a consommé (appel principal, tentatives, contexte, retours en arrière, entretien adjacent) divisé par le nombre d'exécutions réussies. Ce chiffre est supérieur au coût naïf du jeton, et c'est le seul chiffre suffisamment honnête sur lequel baser les décisions de tarification. Basez un prix sur le nombre naïf et vous découvrirez l'écart le jour où le taux de tentatives augmente et où votre marge s'évapore.

Mesurez par course. Incluez les échecs, les tentatives, le contexte, le ménage. Le numéro naïf est un numéro marketing ; c’est l’honnête qui dirige l’entreprise.

Le piège du rabais

Les modèles moins chers sont une tentation qui se manifeste sur une feuille de calcul. Regardez le taux par jeton, regardez le taux du modèle haut de gamme, notez que l'un est une fraction de l'autre et concluez que vous devriez acheminer plus de travail vers le modèle le moins cher pour économiser de l'argent. C'est un instinct naturel et, le plus souvent, il est faux, car l'axe sur lequel vous optimisez est le mauvais axe.

Le bon axe n'est pas le coût par jeton. C'est le coût par résultat. Un modèle bon marché qui nécessite trois tentatives pour réussir une tâche coûte trois fois le prix par jeton pour cette tâche, et si un modèle plus cher avait réussi du premier coup, le choix « bon marché » était en réalité plus cher. Chaque tour supplémentaire qu'un modèle bon marché prend pour obtenir la bonne réponse fait perdre son accord apparent, et souvent l'écaillage continue au-delà du point de croisement où le modèle cher était depuis le début l'option honnête la moins chère.

La façon dont cela se manifeste dans les boucles agentiques est particulièrement punitive. Un modèle bon marché au milieu de la boucle d'utilisation des outils d'un agent qui analyse mal une réponse, appelle un outil avec le mauvais argument ou produit une sortie mal formée déclenche non seulement sa propre nouvelle tentative, mais potentiellement une série d'entre elles, en cascade dans la boucle jusqu'à ce que l'agent récupère ou que la boucle se termine. Chaque trébuchement intérieur coûte plus de jetons que l'appel direct, et l'économie de la boucle se détériore à mesure qu'il y a de trébuchements. Le modèle bon marché par jeton qui trébuche constamment n’est pas la bonne affaire suggérée par la feuille de calcul.

Il existe un deuxième mode de défaillance qui concerne le volume plutôt que les tours. Les modèles bon marché incitent les praticiens à les utiliser davantage – en effectuant plus d’appels parce que chacun semble abordable. Ce volume accru peut pousser les dépenses totales au-delà de ce qu’aurait coûté une utilisation plus disciplinée et plus clairsemée du modèle coûteux. La réduction a modifié le comportement, et le changement de comportement a englouti les économies. L’ancrage sur le coût unitaire occulte à chaque fois ce phénomène.

La bonne façon de raisonner est de mesurer le coût d’un résultat positif, et non le coût d’un jeton ou d’un appel. Combien coûte la production de cet artefact, bout à bout, toutes tentatives et détours compris, sur ce modèle ? Calculez ce nombre pour chaque modèle candidat sur la même tâche, et le modèle bon marché par jeton perd souvent. Lorsqu'il ne perd pas – lorsqu'il s'agit vraiment du bon choix – vous pouvez lui acheminer le travail en toute confiance, car votre classement est basé sur l'argent réel dépensé par livrable réel.

Celui-ci se connecte directement au routeur du chapitre 15, où se trouve la mesure du coût par résultat lorsqu'elle fonctionne bien. Le routeur ne trie pas par prix de jeton ; il s'agit d'un tri selon les performances mesurées sur une classe de tâche spécifique, mis à jour à mesure que les modèles changent. L'itinéraire repose sur une métrique honnête et le bon marché qui survit est réel ; itinéraire sur la feuille de calcul et vous passerez un quart d'heure à rechercher une bonne affaire qui n'a jamais existé.

Achetez le résultat, pas le jeton. Mesurez de bout en bout, par artefact réussi. Un jeton bon marché qui trébuche coûte cher ; un jeton cher qui arrive du premier coup peut être une bonne affaire. Itinéraire en conséquence.

Prix ​​fixe vs T&M

Deux façons de facturer un engagement client se situent de part et d’autre d’une répartition des risques très réelle, et le choix entre elles indique au client – ​​et à vous-même – qui va manger les surprises. Le prix fixe dit que vous les mangez ; le prix reste le même, peu importe ce qui se passe réellement à l’intérieur de l’œuvre. Le temps et les matériaux disent que le client les mange ; vous facturez ce que vous dépensez, et si le travail s'avère deux fois plus long, ils paient deux fois plus. Dans le domaine de l'IA, ces choix ont plus de poids que dans le conseil traditionnel, car le compteur fonctionne sous les deux parties, contrairement à une équipe fixe d'humains.

Le prix fixe est la bonne forme lorsque la portée est véritablement claire et connue. Vous avez déjà effectué ce type de travail, vous savez combien d'heures et de jetons cela prend, et vous pouvez proposer en toute confiance un prix qui reflète votre coût réel plus une marge. Le client bénéficie de prévisibilité. Vous obtenez la récompense de l’efficacité : si vous pouvez livrer en deux fois moins de temps, vous conservez la différence. Les deux parties bénéficient de la clarté, ce qui est réellement ce que vend le prix fixe.

T&M est la bonne forme lorsque la portée n'est pas claire. Nouveau client, nouveau travail, une spécification que vous ne pouvez pas citer avec un visage impassible parce que vous le devineriez. Dans ces conditions, T&M protège les deux côtés : vous ne sous-cotez pas et ne faites pas faillite en essayant de livrer, et le client ne paie pas trop cher pour un risque imaginé que vous deviez évaluer. Le problème est qu'il perd la prévisibilité et vous assumez la charge de suivre et de déclarer avec précision ce que vous dépensez, car leur confiance repose sur l'honnêteté de votre grand livre.

La complication spécifique à l’IA est que même dans le cadre d’un engagement à prix nominalement fixe, les coûts du modèle évoluent sous les deux parties. Un contrat à prix fixe proposé au premier trimestre pourrait amener le fournisseur sous-jacent à augmenter ses tarifs au troisième trimestre, et désormais le prix que vous avez accepté ne couvre plus la réalité de la livraison du travail. Le contrat classique à prix fixe supposait que vos intrants – principalement vos propres heures – étaient stables. En IA, ce n’est pas le cas ; une fraction substantielle de vos frais de livraison est un taux variable que vous ne contrôlez pas. Ainsi, le prix fixe pour l'IA doit générer une marge plus importante que le prix fixe pour le conseil traditionnel, ou bien inclure une clause qui permet aux modifications de prix du modèle de se répercuter sur le client.

Le mode de défaillance que j’ai observé le plus souvent est celui du prix fixe sur une portée floue. Vous citez avec confiance sur une spécification qui semblait solide, le travail commence et il devient évident en une semaine que le travail réel est trois fois supérieur à ce que la spécification décrit. Vous êtes désormais bloqué sur un prix qui garantit une perte, et chaque heure passée à en sortir est une heure que vous ne pouvez pas consacrer à payer du travail. L’instinct à ce moment-là est de manger et d’espérer, et la bonne décision est de renégocier – honnêtement, avec la portée qui se glisse sur la table – parce que brûler la bonne volonté en livrant tard et à bas prix est pire qu’une conversation maladroite à mi-projet sur le prix.

Ma règle de travail est de choisir par défaut T&M pour les nouvelles relations et les nouvelles formes de travail, et de passer au prix fixe une fois que nous avons fait quelques cycles ensemble et que les deux parties savent à quoi ressemble un bon résultat. L'échelle de confiance du chapitre 57 s'aligne sur la structure tarifaire : T&M pour le travail au premier contact, mixte pour les clients connus sur de nouvelles formes, prix fixe uniquement lorsque chacun peut citer le travail avec un visage impassible. Faites correspondre le modèle de tarification au modèle de confiance et les renégociations difficiles à mi-projet disparaîtront pour la plupart.

Fixez le prix uniquement à ce que vous pouvez réellement fixer. Facturez le temps dont la forme est honnêtement inconnue. Espace intégré pour les coûts de modèle variables. Et gravissez les échelons délibérément, pas avec impatience.

Le compteur du client

Il y a un compteur que j'ai oublié lors de mon premier engagement client, et ce n'était pas le mien. C'était celle du client – ​​la facture de son propre fournisseur, qui s'accumulait sous notre travail, s'additionnant au fur et à mesure que nous exploitions son locataire. Mon travail technique était propre ; ma propre facture était raisonnable; puis un mois plus tard, le client m'a envoyé une capture d'écran d'une facture qui l'avait véritablement surpris, et j'ai dû passer l'heure suivante à expliquer pourquoi un système efficace leur avait coûté ce qu'il pensait être très cher.

La leçon est que dans les engagements d'IA, le client dispose souvent de son propre compteur - un compte fournisseur, une facture d'hébergement, une licence par siège, des frais de sortie de données - qui fonctionne en parallèle avec ce que vous lui facturez. Votre facture ne représente que la moitié du tableau. Le système que vous avez construit peut être une merveille d'efficacité tout en offrant au client un total mensuel qui le choque, car son compteur a enregistré le volume que vous y avez introduit. Si vous ne suivez pas leur compteur aussi bien que le vôtre, vous obtenez une vue partielle.

L'échec que cela crée n'est pas technique, c'est un échec de confiance. Le client ne s'est pas inscrit à un système qui produisait des factures surprises. Ils se sont inscrits à un système qui a fonctionné, et une partie de « a fonctionné » signifie « n'a pas coûté plus cher que prévu ». Même si vous ne regardez jamais leur compteur, ils le feront et ils porteront un jugement sur votre professionnalisme en fonction de la correspondance entre le chiffre et leurs attentes. Gérer une facture que l'on ne voit pas est impossible ; l'ignorer met le client mal à l'aise ; la bonne réponse est de l’examiner, de le prévoir et de définir des attentes dès le départ.

Le mécanisme que j'ai choisi consiste à inclure, au début de l'engagement, un tableau de bord des coûts partagés qui montre les deux compteurs : le mien (ma facture pour eux) et le leur (la facture de leur fournisseur pour le système que j'ai construit). Le tableau de bord est un petit artefact ennuyeux, mais il supprime la surprise. Quand le nombre bouge, nous le voyons ensemble. Lorsque nous planifions un mois plus chargé (une campagne, une exécution par lots, un test à grande échelle), nous prévoyons la réponse du compteur avant de nous engager. Aucune des deux parties ne le découvre au moment de la facturation ; les deux le savent avant, et la conversation porte sur la planification et non sur le contrôle des dégâts.

Il y a un corollaire en matière de conception qui en découle, à savoir que les systèmes que vous construisez pour les clients doivent leur être économiquement lisibles. Il devrait être facile pour une partie prenante non technique d'examiner l'activité du mois dernier et de comprendre à peu près pourquoi le chiffre était tel qu'il était. Quels flux de travail ont généré le coût ? Quels locataires ont utilisé combien ? Quelles catégories sont tendances ? Un système qui produit des factures surprises est un système dont les aspects économiques ne sont pas suffisamment lisibles, et la solution consiste à les rendre ainsi – généralement avec le type de dimensions d’attribution des coûts préconisées par le chapitre 31 au niveau du grand livre.

Le principe plus large mérite d'être mentionné directement : votre travail en tant qu'ingénieur dans le cadre d'un engagement client ne consiste pas seulement à rendre le logiciel correct, mais également à rendre prévisible le coût total d'exploitation du logiciel. Un système correct qui produit des factures surprises a échoué dans une partie de son travail, et une partie de la maturité professionnelle dans ce domaine consiste à considérer le compteur du client comme votre responsabilité, et pas seulement la leur. Personne ne veut d’un projet de loi qu’il n’a pas vu venir, et les prévisions ne coûtent pas cher ; fais-le.

Surveillez le compteur du client. Prévoyez les mouvements. Rendre l’économie lisible. La relation survit aux surprises ; il ne survit pas aux factures surprises.

Rapprochement de fin de mois

La quatrième partie se termine sur un rituel : le dernier jour de chaque mois, ou le premier du mois suivant, est consacré à faire correspondre ce que dit mon grand livre avec ce que disent les factures de mes fournisseurs. La réconciliation ressemble à une corvée comptable, et mécaniquement elle l’est ; stratégiquement, c'est le moyen le plus fiable dont je dispose pour savoir ce qui a changé sous moi au cours des trente derniers jours.

La mécanique est simple. Extrayez le coût agrégé du grand livre pour le mois, par fournisseur et par pool. Retirez la facture pour la même période, du même fournisseur. Comparer. Dans un mois idéal, ils correspondent, et je clôture le rapprochement en vingt minutes et je passe à autre chose. Dans un mois réel, ils ne correspondent pas, et la divergence réside dans l'endroit où se trouvent les informations utiles. Un écart signifie soit que mon grand livre est erroné (un bug dans l'enregistreur, une course non étiquetée quelque part) ou que la facturation du fournisseur a changé (un nouveau tarif, un nouveau pool, de nouveaux frais), et dans les deux cas, le fait que je l'ai détecté lors du rapprochement plutôt que des mois plus tard compte.

La discipline est que cela se produit tous les mois, sans faute. Pas « quand je me souviens » ou « quand j'ai le temps » – mensuellement, à un jour fixe, comme non négociable. La raison en est que les divergences s’aggravent. Si un petit changement de taux s'est produit en mars et que je n'ai effectué un rapprochement qu'en juin, j'ai mal évalué pendant trois mois, et chaque décision en aval (devis des clients, calculs de fidélisation, élargissement ou non d'une flotte) a été prise sur la base de chiffres erronés. La cadence mensuelle signifie que le plus grand décalage que vous aurez jamais à résoudre dure trente jours, ce qui est mauvais mais récupérable. Six mois de profondeur sont une véritable crise d’hygiène financière.

L’apprentissage qui ressort du rituel est ce qui en vaut la peine. Chaque rapprochement m'apprend quelque chose sur la réalité de facturation actuelle – de nouveaux frais apparus, un tarif qui a été ajusté en douceur, un pool qui a reçu un compteur différent – ​​et ces observations se répercutent directement sur la carte des tarifs du chapitre 19 et la table de routage du chapitre 15. L'économie change constamment ; c'est la réconciliation que je remarque réellement, plutôt que de supposer que les chiffres d'aujourd'hui sont toujours valables. Les pratiquants qui ne se réconcilient pas ne se trompent pas sur le prix actuel ; ils fonctionnent simplement sur le modèle mental de l’année dernière.

Il y a un bonus qui apparaît avec le temps, c'est l'intuition. Après suffisamment de rapprochements, j'ai construit un modèle approximatif de la façon dont chaque fournisseur facture, lorsqu'il a tendance à modifier ses tarifs, quels éléments de la facture sont stables ou volatiles. Cette intuition vaut de l’argent réel : cela signifie que je peux citer les clients avec plus de confiance, prévoir leurs compteurs avec plus de précision et repérer les anomalies plus rapidement, car je sais à quoi ressemble la normale. Rien de tout cela n’est disponible pour quelqu’un qui n’a jamais comparé son grand livre à ses factures.

La dernière chose qu’il faut dire à propos du rituel est qu’il doit se terminer par une note écrite. Ce n’est pas une feuille de calcul pleine de chiffres ; une phrase ou deux décrivant ce qui a changé ce mois-ci, ce qu'il faut regarder le mois prochain et si quelque chose nécessite une action au-delà de toute reconnaissance. Les rapprochements qui ne laissent aucune trace sont le même mode d'échec que les exécutions sans surveillance qui ne laissent aucune trace : la mémoire de ce que vous avez remarqué se désintègre rapidement et le mois prochain, vous redécouvrirez la même chose que vous saviez déjà. Une note est ce qui rend l’intuition composée plutôt que réinitialisée.

Réconciliez-vous chaque mois. Enquêtez sur chaque inadéquation. Alimentez la carte des tarifs. Écrivez la note. C’est ainsi que vous évitez que les aspects économiques ne vous surprennent – ​​et que la surprise, lorsqu’elle survient, est petite et lisible au lieu d’être catastrophique et cachée.

MECE en pratique

Le chapitre 4 a plaidé en faveur de la MECE – mutuellement exclusive, collectivement exhaustive – en tant que discipline qui transforme un ensemble de compétences en un système d'exploitation. Ce chapitre est à quoi cela ressemble lorsque je l'applique réellement à une suite live, car le principe abstrait est simple et la pratique quotidienne est l'endroit où la plupart des tentatives échouent. MECE n’est pas un audit ponctuel ; c'est un travail de jardinage continu.

Le geste le plus utile que je fais tous les deux mois est de regrouper toutes les compétences que je possède sur une grille – les piliers sur le côté, les compétences en haut – et de marquer à quel pilier appartient chaque compétence. Ce que je recherche, c'est le modèle de lignes et de colonnes : chaque compétence doit résider dans exactement un pilier (une seule marque par colonne), et chaque pilier doit avoir certaines compétences (pas de lignes vides). Lorsque deux compétences marquent un même pilier et que l’une d’elles pourrait aussi se justifier dans un autre, j’ai un chevauchement ; quand un pilier n'a rien qui le pointe, j'ai un vide.

Les chevauchements sont les plus faciles à corriger. Lorsque deux compétences se chevauchent véritablement, l’une d’elles absorbe l’autre et le perdant devient obsolète. Ce que vous ne pouvez pas faire, c'est laisser le chevauchement subsister - car dès que deux compétences résolvent le même problème, la porte d'entrée du chapitre 3 ne peut plus tracer de manière déterministe, et je dois à nouveau choisir entre elles à chaque fois. Le chevauchement n'est pas un problème d'ordre ; c'est un problème fonctionnel pour la couche de routage.

Les lacunes sont plus intéressantes car elles désignent la prochaine chose à construire. Un pilier vide signifie qu'il y a un travail que je fais à la main chaque semaine et qui ne nécessite aucune compétence, et une fois que vous voyez le vide dans la grille, vous ne pouvez pas l'ignorer. Cet écart devient automatiquement le sommet de la file d'attente pour le développement des compétences - je n'ai pas à décider sur quoi travailler, me dit le pilier manquant. La planification de la feuille de route par l'audit MECE est l'un des secrets les mieux gardés de la discipline : on n'invente pas la feuille de route, on la lit hors de la grille.

La discipline qui permet à cela de fonctionner au fil du temps est d’être prêt à se reformer lorsque le monde bouge. Les cinq piliers que j'ai nommés au chapitre 4 ne sont pas sacrés ; ils constituent actuellement la meilleure décomposition du travail que je fais réellement. Lorsque mon travail change – un nouveau type d’engagement, une nouvelle classe d’artefacts, un changement dans l’origine de la valeur – les piliers devront peut-être également changer. S'accrocher aux piliers d'hier parce qu'ils sont familiers, c'est ainsi qu'une suite MECE devient silencieusement une suite héritée. Tous les quelques audits, demandez-vous si les piliers eux-mêmes tiennent toujours, et pas seulement si les compétences y correspondent.

Il existe une discipline subtile concernant la dénomination, à savoir que les noms de compétences doivent décrire leur travail dans le vocabulaire du pilier, et non leur mécanisme interne. Une compétence nommée d'après ce qu'elle fait à l'intérieur - "exécuter un sous-processus avec des indicateurs" - est une compétence qui ne peut pas être échangée contre une meilleure implémentation car le nom a verrouillé ses tripes sur son identité. Une compétence nommée d'après son travail – « admission » ou « proposition » - peut être entièrement réimplémentée en dessous et être toujours la même compétence de l'extérieur. Nom pour le rôle, pas pour les machines, et la suite reste malléable.

Auditez la grille. Tuez les chevauchements. Construisez pour combler les lacunes. Re-pilier quand le monde bouge. Nommez les compétences par rôle. Ce n'est pas MECE comme un slogan mais comme une habitude de jardinage mensuelle.

Pipelines axés sur l’admission

Chaque véritable pipeline que j'ai construit commence par une étape d'admission, et il m'a fallu un certain temps pour comprendre pourquoi ce modèle continuait à émerger de lui-même. L'admission – l'étape qui transforme les entrées brutes et non structurées en une représentation interne bien formée – est l'interface entre le monde désordonné et la machine bien rangée. Sautez-le, ou faites-le mal, et chaque étape suivante hérite du désordre.

La forme naïve d’un pipeline est que chaque étape opère directement sur ce que l’étape précédente a produit, depuis l’entrée originale jusqu’à l’artefact final. Cela fonctionne pour les petits pipelines avec des entrées prévisibles. Cela s'effondre dès que l'entrée varie (différents clients apportant différents formats de fichiers, différentes formes de données, différents niveaux d'exhaustivité) car chaque étape en aval doit désormais gérer de manière défensive chaque variation de ce qui est entré. Le désordre se propage.

Intake résout ce problème en contenant la variation exactement à un seul endroit. Le travail de l'étape d'admission consiste à accepter toute forme étrange que le monde envoie, à la normaliser dans la représentation interne et à transmettre cet objet propre à tout ce qui se passe en aval. Désormais, le reste du pipeline ne voit que la forme nette, quel que soit ce qui entre. Toute la laideur du monde réel réside dans l'admission, là où elle appartient, et l'intérieur du système reste sain d'esprit.

Il y a un principe de conception qui va de pair avec cela et auquel je fais confiance plus que quiconque : mettre le laid sur les bords, garder le milieu beau. Les systèmes réels ne choisissent pas leurs entrées, mais ils choisissent où ils les normalisent. Un pipeline dont le code interne tente de gérer chaque bizarrerie de chaque entrée possible est un pipeline qui continuera à développer des verrues à mesure que de nouvelles bizarreries arriveront. Un pipeline dont l'intérieur fonctionne sur une forme propre et fixe est un pipeline qui reste élégant à mesure que les entrées se multiplient, car chaque nouvelle entrée ajoute une variante d'admission, pas une verrue au milieu.

La discipline subtile est que l'admission doit être stricte. Il doit examiner les données entrantes et décider définitivement si elles sont utilisables, et rejeter celles qui ne le sont pas. Une entrée trop permissive laisse passer des données mal formées à l'intérieur, auquel cas la promesse d'une « forme propre à partir de maintenant » est rompue et le code en aval doit à nouveau se défendre. Rejetez tôt, rejetez bruyamment et rendez le message de rejet suffisamment clair pour que l'expéditeur sache quoi corriger. Un apport strict est la garantie dont tout le reste dépend.

La prise d’air devient également le lieu naturel où accrocher certains éléments de qualité de vie. Le suivi de la provenance – d'où proviennent ces données, quand, de qui – est le travail de l'admission, car c'est à ce moment-là que les données passent de l'extérieur vers l'intérieur. La déduplication y appartient. Il en va de même pour la conversion de forme canonique (dates en ISO, unités en SI, identifiants de même forme). Faites tout cela dès l’admission et vous n’aurez plus jamais à recommencer ; faites-le en aval et vous le ferez partiellement à cinq endroits différents.

Démarrez chaque pipeline par une étape d’admission. Faites-en la seule étape qui touche le monde en désordre. Normalisez dans une forme interne fixe, rejetez de manière agressive et laissez l'intérieur rester propre. Tout le reste dans la suite devient plus facile lorsque l'apport porte son poids.

L'interface de l'adaptateur, revisitée

Le chapitre 16 a présenté l'adaptateur comme la trappe de secours qui maintient les décisions réversibles. Ce chapitre consiste à appliquer la même idée à un niveau supérieur, à la frontière entre une compétence et les services extérieurs dont elle dépend, car une compétence qui code en dur ses prestataires est une compétence qui vieillit mal, et les compétences durent suffisamment longtemps pour que mal vieillir soit un réel problème.

Chaque compétence que je garde dans la suite pendant plus de quelques mois finit par communiquer avec au moins un service externe : un fournisseur de modèles, une API, une base de données, un compartiment de stockage. La manière naïve de créer une compétence consiste à lier directement ces services : la compétence connaît le fournisseur spécifique, l'appelle par son nom et subit les conséquences lorsque le fournisseur change ou devient obsolète. La version adaptateur enveloppe chaque service externe derrière une petite interface convenue, et la logique de base de la compétence ne communique qu'avec l'interface. Même argument que le chapitre 16, dans une portée différente.

Le gain au niveau des compétences est particulièrement élevé, car les compétences sont les éléments que je souhaite réutiliser dans les engagements et les bases de code. Une compétence qui code en dur un fournisseur spécifique à un client (un CRM particulier, un compartiment de stockage particulier) ne peut pas être réutilisée, car le client suivant ne dispose pas de ce fournisseur. Une compétence qui enveloppe le fournisseur derrière un adaptateur peut être réutilisée partout, car chaque engagement peut intégrer sa propre implémentation concrète derrière la même interface. La réutilisabilité est un dividende direct du découplage.

Le mode d'échec que j'ai observé à plusieurs reprises est celui des compétences qui développent progressivement les adaptateurs et finissent par être à moitié adaptées. La première version se lie directement à un fournisseur. Plus tard, un deuxième fournisseur est nécessaire, donc une condition est ajoutée : « si le fournisseur A, faites X, sinon Y ». Désormais, la compétence dispose d'un adaptateur implicite, mais il est réparti dans le code sous forme de logique de branchement plutôt que sous forme d'interface propre. L'ajout d'un troisième fournisseur est pénible car chaque succursale doit être mise à jour à chaque emplacement. L'état à moitié adapté est pire que la version purement liée (qui était au moins honnête) ou qu'un véritable adaptateur (qui aurait contenu la variation).

La discipline qui permet d'éviter le marécage à moitié adapté est de retirer l'adaptateur le plus tôt possible, même lorsqu'il n'y a qu'un seul fournisseur. Cela ne coûte presque rien de définir une petite interface et de mettre votre premier fournisseur derrière elle, et dès qu'un deuxième fournisseur arrive, vous êtes déjà prêt. L'alternative – attendre que le deuxième fournisseur force le problème, puis moderniser un adaptateur via une base de code qui a développé la logique de branchement – ​​est coûteuse d'une manière qu'il est facile de sous-estimer jusqu'à ce que vous l'ayez fait plusieurs fois.

Il y a un dividende de test qui touche particulièrement durement la couche de compétences. Étant donné que chaque service externe se trouve derrière une interface, une compétence peut être testée par rapport à un adaptateur stub qui renvoie des réponses prédéfinies, sans aucun appel en direct, sans coût de jeton, en millisecondes. Les suites de tests qui seraient autrement lentes, instables et coûteuses deviennent rapides et bon marché. Et comme le stub est une implémentation de première classe de l'interface, le même ensemble de tests fonctionne, que le fournisseur sous-jacent soit réel ou faux, ce qui signifie que le test lui-même n'a pas besoin de changer lorsque le fournisseur le fait.

Les adaptateurs au niveau des compétences ont la même idée que les adaptateurs ailleurs : dessinez l'interface là où le monde est incertain, enveloppez les implémentations concrètes derrière elle, gardez le noyau propre. À l’échelle des compétences, les bénéfices de la réutilisabilité et de la testabilité s’accumulent, car les compétences durent suffisamment longtemps pour que la composition soit réelle.

Sources de données échangeables

Si le chapitre 43 concernait en principe l'emballage des fournisseurs derrière des adaptateurs, celui-ci concerne le cas spécifique qui revient le plus souvent dans la pratique : échanger la source de données sous une compétence sans rien changer réellement à la compétence. Les sources de données sont la dépendance externe la plus volatile dont je dispose, et construire dès le départ leur capacité d'échange fait la différence entre une compétence que je peux déplacer d'un engagement à l'autre et une compétence qui reste bloquée dans l'engagement dans lequel elle est née.

Le modèle concret est simple. Quelle que soit la tâche de la compétence (enrichir le profil d'une personne, rechercher un produit, récupérer un document), cette tâche est exprimée comme un appel à une interface et non à une source de données spécifique. Derrière l'interface, il peut y avoir une API en direct aujourd'hui, un cache gratté demain, la propre base de données d'un client le lendemain. La compétence s'en fiche ; sa logique opère sur la forme promise par l'interface, et ce sont les implémentations de l'interface qui changent. La source de données devient un plug-in et non une dépendance matérielle.

La raison pour laquelle les sources de données méritent la forme de découplage la plus forte est qu’elles constituent l’élément le plus susceptible de changer contre votre volonté. Les API deviennent obsolètes. Les conditions de service se resserrent. Changements de prix. Un client insiste pour que vous utilisiez son propre entrepôt de données au lieu d'une source externe. N'importe lequel de ces événements serait catastrophique si la compétence était soudée à une source spécifique, et chacun d'eux devient un échange d'implémentation de routine lorsque la source se trouve derrière une interface. Ce n'est pas hypothétique - cela m'est arrivé plus de fois que je ne peux le compter, et à chaque fois, les compétences qui avaient des adaptateurs ont survécu sans incident tandis que les compétences qui n'avaient pas besoin d'être réécrites.

Il y a un piège spécifique à surveiller à la limite de la forme. Différentes sources représentent des données similaires différemment : une API l'appelle « e-mail », une autre l'appelle « adresse_e-mail », une troisième les imbrique dans un objet « contact ». Si l'interface expose la forme de la source, l'échange de sources nécessite la mise à jour de chaque consommateur en aval pour qu'il corresponde à la nouvelle forme, ce qui va à l'encontre de l'essentiel. L'interface doit exposer une forme interne indépendante de toute source ; le travail de chaque implémentation est de traduire la forme de la source en sa forme interne. Interface d’abord, puis implémentations correspondantes – jamais l’inverse.

Le modèle s’étend au-delà des simples API. J'utilise la même discipline pour le stockage : parfois j'écris sur S3, parfois sur le partage de fichiers d'un client, parfois dans un répertoire local pendant le développement. Tous les trois sont la même interface : "mettez cet artefact quelque part et rendez-moi la référence". La compétence ne sait pas et ne s'en soucie pas ; l'implémentation gère les détails. La même histoire se joue pour les bases de données (simulation en mémoire pour les tests, vrai Postgres en production), pour la recherche (Elasticsearch ici, une base de données vectorielle là) et pour les fournisseurs d'authentification. Toute dépendance externe qui pourrait éventuellement bouger devrait se trouver derrière une interface, car « pourrait éventuellement bouger » s'avère être « finira par bouger ».

Il existe une discipline de conception concernant la forme de la représentation interne, qui mérite d'être mentionnée : la forme interne doit être la forme que la logique de votre compétence souhaite réellement, et non un compromis entre ce que diverses sources exposent. Si la compétence a besoin d'une personne avec une adresse e-mail, un nom et un rôle, l'interface promet ces trois champs, proprement. Si une source n'a pas de « rôle », son implémentation crée quelque chose de raisonnable ou renvoie une sentinelle – mais la promesse de l'interface ne se dégrade pas. Concevoir pour répondre aux besoins de l'intérieur ; laissez les implémentations faire le travail de faire correspondre la réalité à cette promesse.

Enveloppez chaque source de données derrière une interface. Concevez l'interface autour de la forme souhaitée par votre logique, et non de ce qu'une source expose. Laissez les implémentations traduire le monde selon vos promesses. Les sources vont et viennent ; la compétence reste.

GitHub comme source de vérité

Chaque compétence que je conserve est dans Git, et chaque dépôt Git est sur GitHub, et cet arrangement n'est pas une nostalgie des outils de développement - c'est un choix spécifique quant à l'endroit où se trouve la version canonique de chaque compétence, car lorsque la vérité est dispersée sur les ordinateurs portables, les captures d'écran et les messages Slack, la vérité n'est nulle part. GitHub est la source de vérité car c'est le seul endroit où « la version actuelle » est un concept bien défini.

L’alternative naïve consiste à conserver les compétences sous forme de fichiers locaux, à les modifier sur place et, occasionnellement, à les sauvegarder. Cela fonctionne pour un praticien solo avec une seule machine, jusqu'à ce que vous ayez une deuxième machine, ou une panne d'ordinateur portable, ou un nouveau sous-traitant qui a besoin des mêmes compétences, ou un client qui souhaite revoir ce que vous utilisez dans le cadre de son engagement. À chacun de ces moments, le modèle des fichiers locaux se brise d'une manière qui coûte cher à démanteler, car la reconstruction de l'historique à partir d'un disque mort est un projet pour lequel personne n'a prévu de budget.

Mettre des compétences dans Git-et-GitHub ne coûte presque rien à mettre en place et est rentable dès l'arrivée de l'un de ces points d'inflexion. L'historique est préservé automatiquement : chaque modification est une validation, chaque version récupérable, chaque différence vérifiable. La collaboration est triviale : un collègue clone le dépôt, il a ce que j'ai. L'avis client est une URL – je leur montre le dépôt, ils voient le code réel qui a été exécuté lors de leur engagement. Et lorsqu’une machine tombe en panne, restaurer la suite de compétences est un nouveau clone plutôt qu’une opération de recherche et de sauvetage.

Il existe une discipline concernant ce qui appartient au repo et ce qui ne l'est pas. Le code de la compétence appartient. La configuration de la compétence appartient. Les tests de compétences appartiennent. Ce qui n'appartient pas, c'est tout ce qui est secret (clés API, informations d'identification, jetons) et tout ce qui est transitoire (répertoires de cache, artefacts générés, sorties d'exécution). Une mauvaise répartition du côté secret est l'erreur la plus lourde que vous puissiez commettre avec un dépôt public ou partagé, et la discipline nécessaire pour garder les secrets secrets doit être intégrée au flux de travail dès le premier jour, et ne pas être mémorisée après une fuite.

La couche GitHub au-dessus de Git ajoute un ensemble de fonctionnalités qui s'avèrent plus importantes que ce à quoi je m'attendais. Les problèmes deviennent un moyen de suivre les bogues et les demandes de fonctionnalités par rapport à la compétence sans polluer le code. Les demandes de tirage deviennent la couture où un changement est examiné avant qu'il n'arrive. Les actions deviennent un moyen d'exécuter des tests automatiquement à chaque poussée. Aucun d’entre eux n’est essentiel au sens où Git lui-même l’est, mais chacun d’eux est le genre de discipline légère qui empêche l’ensemble des compétences de pourrir silencieusement à mesure qu’il grandit.

Le corollaire qui fait que tout cet arrangement fonctionne est qu'une fois que GitHub est la source de vérité, la copie locale sur mon ordinateur portable est une copie de travail, pas l'artefact. S'il s'écarte de ce qui se trouve dans la télécommande, la télécommande l'emporte et mes modifications locales doivent être réconciliées - extraites, fusionnées, poussées - jusqu'à ce que les deux correspondent à nouveau. Traiter le distant comme faisant autorité semble évident et constitue l'habitude mentale spécifique qui empêche le développement distribué de se transformer en un ensemble de forks divergents sans version canonique claire.

Mettez toutes les compétences dans Git. Envoyez chaque commit vers GitHub. Gardez les secrets à l'écart. Traitez la télécommande comme une vérité. L'ensemble de compétences devient un atout qui survit à votre machine, à votre ordinateur portable, à votre système d'exploitation et, éventuellement, à votre carrière.

L'échafaudage des compétences

Chaque compétence que je développe part du même échafaudage, et l'échafaudage n'est pas intelligent – ​​il est ennuyeux, évident et non négociable. Un répertoire tests, un répertoire src, un manifeste, un README, un petit ensemble d'adaptateurs. Rien d'exotique ; rien qui ait pris un mois à concevoir. La raison pour laquelle j’insiste sur la même forme pour chaque compétence est que la forme partagée est ce qui permet aux compétences de composer, et la composition est le lieu où réside l’effet de levier.

Le manifeste est la pièce que j’ai sous-estimée le plus longtemps. Il s'agit d'un petit fichier de métadonnées à la racine de chaque compétence qui déclare à quoi sert la compétence, à quel pilier elle appartient, quelles sont ses entrées, quelles sont ses sorties et avec quelles autres compétences elle compose. Les machines lisent le manifeste pour acheminer le travail ; les humains le lisent pour comprendre ce que fait une compétence sans ouvrir le code. Lorsque les manifestes sont cohérents dans une suite, la porte d'entrée du chapitre 3 peut effectuer son travail de routage de manière déterministe, car chaque compétence se déclare dans le même vocabulaire.

Le répertoire tests n'est pas non plus facultatif, même pour les compétences que je pense que je n'utiliserai qu'une seule fois. Une compétence sans tests est une compétence que je ne peux pas refactoriser en toute sécurité, que je ne peux pas déprécier en toute confiance et que je ne peux pas transmettre à un collègue. Les tests sont la ceinture de sécurité qui me permet de modifier une compétence sans espérer me souvenir de tous les cas extrêmes. Les tests spécifiques que j'écris varient selon la compétence, mais il y en a toujours au moins un : un test de la voie dorée qui exécute la compétence de bout en bout sur des entrées prédéfinies et affirme que l'artefact fonctionne correctement. Ce test unique détecte la plupart des régressions et vaut plusieurs fois son poids.

Le README est le troisième morceau et celui dont je dois sans cesse réapprendre la valeur. Pas pour moi – pour la future version de moi, dans six mois, qui aura oublié à quoi sert cette compétence et pourquoi. Le README est un message du moi présent au moi futur, et il doit supposer que le moi futur ne se souvient de rien des choix de conception, des compromis, du client qui a motivé le travail. Le README de chaque compétence explique à quoi elle sert, comment l'exécuter, quoi la nourrir, ce qu'elle redonne et, surtout, pourquoi la conception a atterri là où elle est arrivée.

Le dossier des adaptateurs est l’endroit où atterrit physiquement la discipline des chapitres 43 et 44. Chaque dépendance externe est un fichier dans ce dossier, enveloppé derrière une petite interface. De nouveaux adaptateurs sont ajoutés ici ; les anciens prennent leur retraite ici. L'uniformité signifie que « comprendre comment cette compétence communique avec le monde extérieur » est résolu en ouvrant un dossier unique et prévisible, et non en parcourant l'ensemble de la base de code.

Une dernière pièce appartient à l’échafaudage, qui est une version. Chaque compétence en a une, et elle se répercute sur chaque changement significatif. Le versioning sémantique est une bonne chose – majeur pour les ruptures, mineur pour les ajouts, correctif pour les correctifs – mais le schéma spécifique compte moins que le fait qu'une version existe. Parce que lorsque le comportement d'une compétence change, tout ce qui en dépend doit être informé, et un changement de version est la façon dont le changement s'annonce.

Manifeste, tests, README, adaptateurs, version. Même forme, toutes les compétences. L’uniformité semble un peu lourde lorsque vous avez trois compétences et s’avère extrêmement payante lorsque vous en avez trente. Construisez l’échafaudage une fois, appliquez-le toujours.

Expressions idiomatiques partagées

Si le chapitre 46 était l'échafaudage physique que partage chaque compétence, ce chapitre concerne l'échafaudage linguistique - le petit ensemble d'idiomes qui reviennent dans chaque compétence et qui donnent à la suite l'impression d'être un langage plutôt qu'un ensemble d'écritures. Expressions idiomatiques dans le sens de « comment nous disons les choses ici » : la manière standard d'enregistrer une exécution, la forme standard d'une erreur, la structure standard d'un résultat. La cohérence à ce niveau est ce qui rend la composition plus facile plus tard.

Le premier idiome est la forme du résultat. Chaque compétence renvoie un résultat de la même forme : un statut (succès ou échec), une charge utile (l'artefact ou la raison de l'échec), un pointeur de trace (où trouver les preuves de l'exécution) et un enregistrement de coût (ce que cette exécution a consommé). Différentes compétences produisent évidemment des charges utiles différentes, mais l’enveloppe autour de la charge utile est identique. Les consommateurs en aval savent comment gérer le résultat de chaque compétence, car celui-ci a la même forme. Les enveloppes uniformes garantissent la sécurité de la composition.

Le deuxième idiome est la forme d’erreur. Lorsqu'une compétence échoue, elle le fait de manière typée : l'échec comporte une catégorie (transitoire, sémantique, terminale, à partir du chapitre 29), un message pouvant être montré en toute sécurité à un humain, une raison interne plus utile pour le débogage et un indice de nouvelle tentative, le cas échéant. Les appelants peuvent répondre aux erreurs de manière déterministe, car les erreurs se décrivent d'une manière que les appelants peuvent inspecter. Les chaînes d'erreur non typées sont la voie vers le chaos, chaque appelant les analysant différemment.

Le troisième idiome est la journalisation. Chaque compétence émet une progression de la même manière structurée : un flux d'événements avec des noms et des charges utiles saisis, correspondant à la structure des événements du chapitre 23. La porte d'entrée et tout orchestrateur peuvent restituer, regrouper et raisonner sur les événements de n'importe quelle compétence sans savoir de quoi il s'agit, car la forme est stable. Si une nouvelle compétence introduit son propre format de journalisation, elle rompt la promesse de composition ; la règle est que la forme de la bûche est celle de la suite, et non celle de la compétence individuelle.

Le quatrième idiome est celui de nommer. Les compétences utilisent les mêmes mots pour les mêmes choses. Un « exécution » signifie partout la même chose : l'invocation d'une compétence contre des intrants, produisant un résultat. Un « artefact » signifie la même chose : une sortie persistante qu'un magasin d'artefacts peut contenir. Une « trace » signifie la même chose : la preuve structurée que la course a laissée derrière elle. La dérive du vocabulaire est l'une des formes les plus silencieuses de dégradation des suites, car le petit changement de nom de chaque compétence ne semble pas nuisible jusqu'à ce que la moitié de la suite appelle le même concept par trois noms différents et que chaque discussion doive être traduite.

Le mode d’échec que j’ai observé avec les expressions idiomatiques est qu’elles sont entretenues par l’attention plutôt que par un mécanisme, et l’attention est une garantie fragile. La chose pratique à faire est donc de mettre les idiomes dans le code – une bibliothèque partagée, un petit ensemble de types, un ensemble de fonctions d’assistance – que chaque compétence importe. Maintenant, la cohérence n’est pas une discipline dont je dois me souvenir ; c'est une dépendance qui s'impose. Dès qu'une compétence s'écarte de la bibliothèque partagée, elle est visible ; au moment où ça dépend de la bibliothèque, c'est aligné par construction.

Enveloppe de résultat, forme d'erreur, flux de journaux, vocabulaire — les quatre idiomes qui transforment un ensemble de compétences en une suite. Mettez-les dans une bibliothèque partagée. Laissez l'individualité de chaque compétence vivre dans sa logique, et non dans la façon dont elle parle d'elle-même. La composition est aussi simple que les expressions idiomatiques sont cohérentes, et c'est la bibliothèque partagée qui les rend ainsi.

Déprécier une compétence

Les suites accumulent des compétences au fil du temps, et elles accumulent également des compétences qui ne devraient plus exister. La dépréciation – l’acte délibéré de retirer une compétence du service actif – est la contrepartie disciplinée de la construction, et la négliger est la façon dont une suite allégée devient silencieusement une suite gonflée. Chaque compétence qui survit à son utilité est une distraction sur la grille et un frein sur le routage.

Les raisons pour lesquelles une compétence mérite d’être retirée sont variées et méritent d’être mentionnées. Parfois, le travail sous-jacent disparaît (un client s'en va, un flux de travail change de forme). Parfois, une meilleure compétence absorbe le travail de l'ancienne (deux compétences qui se chevauchent, une gagne selon le chapitre 41). Parfois, le fournisseur sous-jacent dont dépendait une compétence a disparu, et la réécriture de la compétence auprès d'un nouveau fournisseur n'en vaut pas la peine. Parfois, je regarde une compétence que j'ai acquise il y a deux ans et je me rends compte que je ne me souviens plus pourquoi. Chacun de ces éléments constitue un signal de retraite valable, et honorer ce signal est ce qui empêche la suite de devenir un musée.

Les mécanismes de dépréciation ne sont pas dramatiques. Le manifeste de la compétence reçoit un indicateur obsolète avec une date et une raison. Tout ce qui compose avec la compétence reçoit un avertissement au moment de la construction ou de l'exécution indiquant que sa dépendance est en train d'être retirée. De nouveaux appels à la compétence déclenchent un coup de pouce pour migrer. Après une période de grâce (quelques mois en général), le code de la compétence est transféré vers une branche d'archives du référentiel et cesse d'être routable depuis la porte d'entrée. Ce qui est important c'est que chaque scène soit publique et télégraphiée, donc rien dans la suite n'est surpris par la disparition de la compétence.

Il y a une discipline que j'ai dû apprendre à ne rien supprimer. Les compétences retraitées vont dans les archives, pas à la poubelle. La raison en est que six mois après la retraite, je découvre parfois un scénario dans lequel la compétence obsolète a bien géré, et la relancer - même juste pour référence - est triviale si le code existe toujours quelque part. La suppression est irréversible ; l'archivage est réversible ; Lorsque le coût marginal de rétention est de quelques kilo-octets de disque sur un dépôt que vous conservez déjà, la solution la moins coûteuse consiste à archiver.

Le mode d’échec que je veux nommer est le mode opposé : des compétences qui perdurent bien au-delà de leur véritable utilité parce que la dépréciation semble gênante ou ingrate. Il y a un léger coût psychologique à mettre fin à votre propre travail, en particulier à un travail qui comptait autrefois. Mais l'alternative est pire : une suite pleine de compétences à moitié vivantes que personne ne veut vraiment supprimer est une suite où la table de routage prête à confusion, la grille MECE est un mensonge, et chaque nouvelle compétence doit défendre son existence sur fond de bruit. Le retrait favorise la clarté de la suite ; traitez-le comme tel et cela cesse de ressembler à un rejet du travail passé.

Il existe une règle de dénomination qui permet de signaler le changement : une compétence obsolète ne reçoit pas seulement un indicateur, elle reçoit une note explicite dans son README indiquant "cette compétence est retirée ; le remplacement est X" ou "pas de remplacement - le flux de travail qu'elle servait n'existe plus". La note est destinée au futur moi et à tous ceux qui tombent sur le code archivé et se demandent s'il est toujours d'actualité. Les archives silencieuses sont des archives dangereuses ; ceux documentés sont des références utiles.

Retirez ce qui ne mérite plus sa place. Archivez plutôt que supprimez. Télégraphiez le changement pour que rien ne soit surpris en fonction de la compétence. Documentez la retraite. La suite reste épurée par discipline, pas par accident.

Télémétrie des compétences

Une compétence sans télémétrie est une compétence fonctionnant sur supposition. Vous pensez que c'est utile ; vous pensez que cela réussit la plupart du temps ; vous pensez que les échecs sont rares et assez rares. Ces trois pensées sont des opinions jusqu'à ce qu'elles soient mesurées, et c'est la télémétrie des compétences qui les transforme en faits. Pas glamour ; pas facultatif au-delà d’une certaine taille de suite.

Les mesures qui m'intéressent au niveau des compétences sont volontairement ennuyeuses. Combien de fois cette compétence a-t-elle été invoquée au cours de la semaine dernière ? Quel pourcentage d’appels ont réussi ? Quel est le coût moyen par appel réussi ? Quelle est la durée médiane ? Quel est le taux de nouvelle tentative ? Ces cinq chiffres, mis à jour chaque semaine, m'indiquent l'essentiel de ce que j'ai besoin de savoir sur la santé d'une compétence, et leur absence est ce qui permet aux compétences de pourrir tranquillement sans que je m'en aperçoive.

La raison pour laquelle la télémétrie est particulièrement importante pour les compétences, et pas seulement pour les systèmes dans lesquels elles sont intégrées, est que les compétences constituent l'unité composable de la suite. Une seule compétence peut être appelée à partir d’une douzaine de pipelines différents, chacun avec une fréquence et une criticité différentes. L’agrégation de l’utilisation au niveau des compétences me permet de voir quelles compétences sont porteuses – celles dont dépend chaque pipeline – et lesquelles sont de niche. Les compétences portantes méritent plus de tests, plus de durcissement et une conception d'adaptateur plus soignée ; les compétences de niche peuvent être plus légères. Sans la vue globale, chaque compétence est traitée de la même manière, ce qui n’est efficace dans aucun des deux sens.

Le mécanisme que j'utilise est que l'enveloppe de résultat de chaque compétence (chapitre 47) est enregistrée, par invocation, dans un registre central - en fait le même registre du chapitre 31, étiqueté avec le nom de la compétence. Chaque semaine, une requête d'agrégation extrait les lignes par compétence de la semaine dernière et produit les cinq nombres. Les chiffres me sont livrés sous forme d’un petit rapport tous les lundis. Rien d'extraordinaire - je veux qu'il soit si bon marché à produire qu'il soit toujours produit, et si bon marché à lire que je le lis toujours.

Le seul chiffre qui s’avère étonnamment diagnostique est le taux de réussite. Les compétences dont le taux de réussite diminue au fil du temps sont des compétences dont les hypothèses sous-jacentes s'érodent : un adaptateur qui commence à se briser, une distribution d'entrées qui change, un comportement de modèle qui change. Attraper cette dérive alors qu'elle est encore progressive est beaucoup moins cher que de la découvrir lorsqu'une exécution client échoue visiblement. La télémétrie est le système d’alerte précoce en cas de pourriture silencieuse.

Le deuxième chiffre qui mérite l’attention est le taux de nouvelles tentatives. Un nombre élevé de tentatives signifie soit un problème d'environnement transitoire, soit un problème sémantique échappant au classificateur, et l'une ou l'autre interprétation est exploitable : la première améliore l'infrastructure de fiabilité, la seconde améliore la gestion des erreurs de la compétence. Les compétences avec des taux de nouvelle tentative relativement élevés sont également des compétences avec des coûts légèrement gonflés (selon le chapitre 36), de sorte que le nombre de nouvelles tentatives est un indicateur avancé de la dégradation de l'économie de l'unité.

Enregistrez chaque appel. Agréger chaque semaine. Surveillez le taux de réussite, le taux de tentatives et le coût par résultat. Les compétences qui pourrissent tranquillement se rendent visibles dans la télémétrie – mais seulement si la télémétrie existe. Construisez-le avant d’en avoir besoin.

Quand une compétence veut être un service

La cinquième partie se termine sur une question qui se pose finalement pour toute suite mature : quand une compétence doit-elle cesser d’être une compétence et devenir un service à part entière ? Les deux sont de proches cousins ​​sur le plan architectural, mais ils sont de nature différente, et savoir quand une compétence souhaite obtenir son diplôme fait la différence entre développer votre entreprise et dépasser votre architecture.

Une compétence est un élément de machine composable, invoqué à partir d'un flux de travail et exécuté en cours de processus avec le reste de la machine. Un service est une fonctionnalité indépendante, toujours active, exposée sur une interface, appelée par de nombreux workflows, y compris ceux que vous ne contrôlez pas. La frontière entre elles n'est pas nette : beaucoup de choses vivent confortablement en tant que compétences pendant longtemps et puis, à un moment donné, le fait qu'il s'agisse de compétences commence à ressembler à une contrainte plutôt qu'à une commodité.

Les signaux indiquant qu’une compétence veut devenir un service sont spécifiques et méritent d’être nommés. Premièrement : il est appelé à partir de nombreux workflows qui ne devraient pas avoir à le regrouper individuellement. Lorsqu'une compétence est utilisée par dix pipelines différents et que chaque pipeline doit inclure le code et les dépendances de la compétence, la surcharge de copie est un coût réel et la centralisation de la fonctionnalité en tant que service commence à paraître attrayante. Deuxièmement : il doit conserver l'état lors des invocations (un cache, un index, un limiteur de débit) qui ne peuvent raisonnablement pas vivre dans le processus de courte durée de chaque pipeline. Troisièmement : il doit fonctionner en continu, et pas seulement à la demande : un auditeur, un observateur, un planificateur qui se réveille en cas d'événements externes. N’importe laquelle de ces trois raisons constitue une raison légitime pour obtenir un diplôme.

Les signaux indiquant qu'une compétence pas veut être un service sont tout aussi importants. Une compétence qui est appelée depuis un endroit, qui ne contient aucun état d'appel croisé et qui ne fonctionne qu'à la demande est une compétence qui ne gagnerait rien à obtenir son diplôme, si ce n'est une plus grande surface opérationnelle. Entretenir quelque chose prématurément coûte cher – vous disposez désormais d’un service à sécuriser, surveiller, déployer, faire évoluer et payer – et le gain doit en valoir la peine. La plupart de mes compétences restent des compétences pour toujours, car honnêtement, la plupart de mes compétences n'ont pas besoin d'être des services. L'obtention du diplôme est une exception et non un défaut.

Les mécanismes de la transition, lorsqu’elle se produit, sont moins dramatiques qu’il n’y paraît. Parce que la compétence a été construite sur la base des disciplines d'adaptateur et d'idiome des chapitres précédents, son interface est déjà propre. Le présenter en tant que service signifie envelopper cette interface dans un transport réseau (un point de terminaison HTTP ou un consommateur de file d'attente) et l'exécuter en tant que processus persistant. La logique fondamentale ne change pas ; la coque qui l'entoure le fait. Il s'agit du même modèle « tester une fois, exposer deux fois » du chapitre 12, appliqué à la frontière compétence/service : la logique est stable, seule la surface d'invocation change.

Il existe un risque subtil à nommer d'emblée : une fois qu'une compétence devient un service, son évolution ralentit. Les services comportent des promesses de compatibilité, des obligations de disponibilité et des frais généraux de gestion des changements que les compétences en cours de processus n'apportent pas. L'obtention du diplôme est donc dans la pratique une porte à sens unique : il est techniquement possible de rétrograder un service au rang de compétence, mais socialement, c'est un aveu de dépassement de soi difficile à franchir. Ce qui signifie que la décision d’obtention du diplôme mérite du soin ; c'est le moment où une pièce de votre suite passe de bon marché à changer à cher à changer.

Surveillez les signaux : nombreux appelants, état d’appel croisé, besoin permanent. Diplômé quand ils arrivent, pas quand la tentation se fait sentir. Et acceptez que l’obtention du diplôme est une promotion que la pièce doit mériter, car dès que vous franchissez la ligne, l’ergonomie de l’expérimentation cède la place à l’ergonomie de la production. La plupart des compétences restent des compétences ; c'est une fonctionnalité.

Découverte à la liste

Chaque relation client commence comme un étranger et se termine soit comme un membre de la liste, soit comme un inapte poli, et le processus consistant à déterminer lequel est ce que j'appelle la découverte. Ce sont les premières conversations délibérées et structurées qui indiquent aux deux parties s’il y a un véritable engagement à construire. C'est dans une bonne découverte que se produisent la plupart des victoires et la plupart des gaspillages ; la livraison réelle est plus facile que de déterminer à qui livrer.

La façon dont je structure la découverte est petite et spécifique. Première conversation : que veut réellement le client, dans ses propres mots, sans que je l’interprète ou le recadre ? Deuxième conversation : à quoi ressemble le monde autour de leur problème : les contraintes, les solutions actuelles, les personnes impliquées, l'argent ? Troisième conversation : à quoi ressemblerait le succès dans trois mois, concrètement, et à quoi ressemble l’échec ? Trois conversations ciblées, chacune avec une question claire, chacune pas plus longue que nécessaire. C'est généralement suffisant pour savoir.

Le but de la découverte n'est pas de vendre, mais de découvrir s'il existe une solution qui mérite d'être poursuivie. J'ai appris à résister à l'instinct de convaincre lors de ces conversations. Si l’ajustement est bon, il s’annonce ; Les deux parties ressortent clairement de la troisième conversation qu’il y a quelque chose à construire. Si l'accord ne convient pas, cela s'annonce également, et la démarche éthique consiste à le dire et à se séparer en bons termes. Essayer de forcer un mauvais ajustement à un bon est coûteux pour moi, pire pour le client, et se termine de manière fiable par un engagement raté qui nuit aux deux réputations.

Les signaux indiquant qu’une concordance est réelle s’avèrent simples. Le client a un vrai problème, pas une vague ambition. Ils peuvent exprimer clairement à quoi ressemblerait une solution, même grossièrement. Ils ont l’autorité et le budget pour réellement s’engager – et non pas « nous devrons gérer cela par trois comités ». Et ils sont prêts à faire le travail que la découverte elle-même exige : se présenter, répondre aux questions, être honnêtes. Lorsque ces quatre personnes sont présentes, la troisième conversation se termine généralement avec les deux parties demandant « et alors, quelle est la prochaine étape », ce qui est bon signe.

Les signaux d’un mauvais ajustement sont tout aussi simples et plus faciles à dissuader de s’en apercevoir. Le problème se déplace d’une conversation à l’autre. Le budget n'est pas clair. Les parties prenantes ne cessent de changer. Les questions semblent évasives. Chacun d’entre eux, à lui seul, peut être innocent ; deux ou plus ensemble, c'est généralement l'univers qui vous dit de passer à autre chose. Lorsque j'ai ignoré ces signaux, j'en ai payé le prix à chaque fois et j'ai appris à leur faire confiance plus rapidement.

La question de la liste – décider quels clients conserver à long terme – est la même évaluation en cours en continu après la découverte. Tous les trois ou six mois, je regarde qui est sur la liste et je me demande : est-ce toujours la bonne personne ? Est-ce qu'on obtient tous les deux ce pour quoi nous sommes venus ? Est-ce que je dirais oui à la découverte avec ce client si nous commencions aujourd’hui ? Un oui honnête les maintient ; un non honnête est l’incitation à avoir une conversation difficile sur la conclusion. Les listes qui ne changent jamais sont des listes qui dérivent tranquillement vers des engagements médiocres qu’aucune des parties ne veut nommer.

Trois conversations. Observez les signaux. Dites non quand c'est un non. Gardez la liste révisée. Les clients que vous servez bien sont ceux que vous avez sélectionnés honnêtement.

La fusion comme fonction de forçage

Il existe un type spécifique d'engagement client que je considère comme une fusion – le type où l'ambition est bien plus grande que les ressources, et où toute l'équipe va devoir se plier à la contrainte pour que cela fonctionne. Ces engagements me terrifient et ils produisent aussi, sans exception, le meilleur travail que j'ai jamais réalisé. La contrainte est le point.

Ce que partagent les clients de Fusion, c'est qu'ils arrivent avec un problème réel, spécifique et difficile, et un budget réel, spécifique et insuffisant pour la manière standard de le résoudre. Si nous procédions de la manière habituelle en matière de conseil – une équipe de six, six mois, un plan de projet, une série d'ateliers – le coût serait prohibitif. Les clients Fusion ne recherchent pas la manière habituelle ; ils recherchent quelqu'un qui peut avoir la même ambition mais qui trouve une voie complètement différente pour y parvenir. C’est dans cette « voie complètement différente » que le travail natif de l’IA excelle discrètement, car un pipeline agent bien informé peut absorber le travail qui nécessitait auparavant une équipe de six personnes.

La fonction de forçage est ce qui se passe sous cette contrainte. Lorsque vous ne pouvez pas vous contenter de recruter du personnel, vous devez être parfaitement clair sur ce qui compte réellement et abandonner tout le reste. Chaque réunion doit mériter sa place. Chaque livrable doit avoir la forme minimale qui répond à la vraie question du client. Chaque abstraction doit être justifiée par la question : « serait-elle également ici dans une version plus petite de ce projet ? » La rareté n’est pas un fardeau – c’est ce qui clarifie le travail, car elle nous oblige à nous poser constamment la question de savoir ce que nous couperions si nous devions absolument le faire, et la réponse à cette question est généralement « la majeure partie ».

Le mode d’échec créé par les clients de Fusion est qu’ils attirent le mauvais type de consultant – celui qui dit oui à l’ambition sans honnêtement en chiffrer le coût et livre une version diluée d’un projet normal dans le cadre d’un budget contraint. Ce n'est pas Fusion ; c'est un engagement de mauvaise valeur prétendant en être un. La vraie fusion signifie restructurer l'exécution elle-même afin que le budget limité finance réellement un résultat ambitieux, ce qui nécessite une méthode de travail véritablement différente, et non une version au rabais de l'ancienne méthode. Si vous ne pouvez pas restructurer, n'acceptez pas l'engagement.

En pratique, la restructuration ressemble à un recours intensif à la discipline dont parle tout ce livre. L'équipe de nuit effectue le travail mécanique ; la pile de pompons est réservée aux appels de jugement face au client ; l'échelle des artefacts n'est gravie que dans la mesure où le résultat spécifique l'exige. Un projet Fusion utilise la machine pour faire ce qui autrement nécessiterait une équipe, et utilise les humains – moi et le client – ​​là où leur place est irremplaçable. C'est l'argument du système d'exploitation et non de la boîte à outils, financé par un client avec un résultat spécifique en tête.

Il y a un corollaire en matière de sélection de clients auquel j'ai mis du temps à faire confiance. Les clients Fusion ont tendance à être les meilleurs clients, précisément parce que la contrainte agit comme un filtre des deux côtés. Seuls les clients qui peuvent accepter une véritable restructuration – le client rencontrant moins de personnes, le livrable arrivant sous une forme différente, le processus semblant différent – ​​s’engageront de cette manière. Et les clients qui peuvent accepter cette restructuration sont généralement ceux qui réfléchissent le plus clairement à ce dont ils ont réellement besoin, c’est-à-dire exactement le client que vous recherchez.

La contrainte de temps d’ambition est égale à la clarté. Les clients Fusion apportent les deux. Restructurez honnêtement la livraison, ou dites non ; il n'y a pas de version intermédiaire diluée qui fonctionne.

Le badge MOCK

Le chapitre 17 a présenté le commutateur simulation/live en tant que mécanisme et a énoncé une règle sur laquelle je souhaite consacrer un chapitre entier : les données simulées doivent être visiblement et indubitablement moquées. Ce chapitre concerne le badge – une convention visuelle spécifique que j'applique sur chaque page et chaque artefact affichant des données prédéfinies, et pourquoi ce badge mérite sa place dans la conception.

Le badge lui-même est petit et impossible à manquer. Une courte étiquette — « MOCK » ou « SAMPLE DATA » — dans une couleur qui se démarque de l'interface utilisateur environnante, positionnée à un endroit où l'œil ne peut s'empêcher de la voir. Ni dans une note de bas de page, ni dans une info-bulle, ni dans un gris subtil. Il doit être suffisamment fort pour qu'une personne raisonnable jetant un coup d'œil à l'écran le remarque en une seconde, car un badge qui nécessite une attention n'est pas un badge, c'est une décoration.

La raison pour laquelle la norme de visibilité doit être si élevée est que les données simulées sont plus convaincantes que les praticiens ont tendance à le croire. Les simulations bien conçues semblent réelles. Ils sont souvent conçus pour paraître réels, car le but de les montrer est de rendre concrète l'expérience éventuelle. La tension est que les mêmes propriétés qui rendent les simulations utiles – plausibilité, exhaustivité, finition esthétique – les rendent dangereuses lorsqu’elles sont interprétées à tort comme des données réelles. Le badge est le contrepoids qui empêche la plausibilité de se transformer en tromperie.

Le mode d'échec que j'ai observé à plusieurs reprises est qu'un badge subtil permet à une simulation d'être confondue avec de vrai, une fois, par quelqu'un qui compte. Il peut s’agir d’une partie prenante qui voit une capture d’écran dans un rapport et interprète mal les chiffres. Il peut s'agir d'un collègue qui capture la simulation dans l'e-mail d'un client. Il se peut que, trois mois plus tard, j'oublie quelles pages contiennent encore des données stockées. Chacun de ces éléments crée un coût de confiance en aval qui est disproportionné par rapport à la taille du badge qu'il aurait fallu avoir pour l'empêcher. Fort, c'est bon marché ; l’ambiguïté coûte cher.

Il existe un corollaire qui mérite d'être évoqué : le badge reste actif jusqu'à ce que les données soient véritablement actives, et sa suppression est un acte délibéré. Pas "Eh bien, l'API fonctionne probablement maintenant, nous pouvons retirer le badge". La suppression a lieu une fois que les données réelles ont été confirmées et transitent par la page exacte sur laquelle se trouve le badge. Le badge est une promesse que cette page sera moquée ; le retirer juste avant que la promesse ne cesse d'être vraie est exactement le moment où quelqu'un verra le mauvais numéro. Un retrait prudent est le bon instinct.

Au-delà du visuel, le badge est une fonction forçant le design qui améliore discrètement l’ensemble du produit. Parce que je sais que le badge sera visible par tous ceux qui verront la page, je suis moins tenté de sur-polir l'état simulé - le but n'est pas de cacher la simulation, mais de communiquer la forme. Les décisions concernant les produits prises par rapport à des produits factices honnêtement étiquetés sont de meilleures décisions, car tous ceux qui les examinent savent ce qui est réel et ce qui est réservé. Cette connaissance fait évoluer la conversation de « le chiffre semble-t-il correct » à « la forme du flux fonctionne-t-elle », qui est la conversation qui compte réellement à ce stade.

Insigne bruyant. Impossible de rater. Ne se détache que lorsque la promesse cesse d'être vraie. Et derrière la discipline, un dividende de conception : les simulations honnêtes finissent par produire de meilleures conversations sur les produits que les simulations qui prétendent être réelles. Expédiez toujours le badge.

L'humain dans la boucle comme moment facturable

Dans chaque engagement client, il y a un moment spécifique pour lequel le client paie réellement, et ce n'est pas le moment où la machine produit le résultat. C'est le moment où un humain – généralement moi, parfois eux – examine le rendement de la machine, le juge et décide de la suite des événements. Cet examen est le moment facturable, et comprendre pourquoi est ce qui différencie les engagements que les clients apprécient de ceux qu'ils cessent lentement d'apprécier.

L’instinct dans le travail de l’IA est de valoriser le travail de la machine comme le produit. L'agent a produit autant d'artefacts, c'est donc ce que nous facturons. La tarification basée sur le volume semble naturelle car c'est la machine qui génère le volume. Mais le volume à lui seul n’a pas de valeur pour le client ; le volume qui a été examiné et garanti est. Un artefact non révisé est une ébauche ; un artefact examiné est un livrable. L’écart entre les deux est entièrement dû au jugement humain, et ce jugement est ce dont le client a réellement besoin dans le cadre de l’engagement.

L'implication en matière de tarification est que la structure facturable doit refléter la révision, et pas seulement la génération. Un client ne me paie pas une centaine de brouillons générés par l'IA par semaine ; ils paient pour les vingt qui ont réussi mon examen, et le cadrage autour de ces vingt – qui sont les plus forts, qui sont les plus risqués, qui répondent à la question spécifique sur laquelle ils se penchent ce mois-ci. La machine pourrait en produire mille ; mon rôle est de compresser cela en un petit nombre qui transmet un signal utile, et la tarification reconnaît que la compression vaut la peine d'être payée.

Cela reformule un argument qui revient régulièrement dans le conseil en IA : « l’IA ne fait-elle pas l’essentiel du travail ? Non, ce n'est pas la partie qui vaut la peine d'être payée. L'IA effectue l'essentiel du travail mécanique : la production en volume, les ébauches initiales, la récupération et la transformation. Le travail précieux – décider quel résultat sera envoyé, faire correspondre le résultat au contexte, détecter les erreurs subtiles qui pourraient embarrasser le client – ​​reste humain, et c'est la part que le client paie pour avoir bien fait. Lorsque les praticiens sous-évaluent leur travail en supposant que l’IA en fait l’essentiel, ils évaluent la moitié mécanique et donnent gratuitement la moitié du jugement.

Il y a un modèle de livraison qui découle de ce cadrage. Au lieu de montrer aux clients tout ce que la machine a produit, je leur montre ce que j'ai choisi parmi ce que la machine a produit – avec de brèves notes expliquant pourquoi. Le format de présentation raconte l'histoire : "la machine a généré cent variantes ; voici les sept que je recommande pour ce mois-ci, classées, avec un paragraphe sur le raisonnement pour chacune". Le client voit immédiatement la valeur de l’avis. Ils ne cherchent pas une décharge; ils examinent le jugement appliqué au volume, qui est un produit fondamentalement différent.

Le corollaire qu’il m’a fallu le plus de temps pour intérioriser est que ce cadre protège la viabilité économique de l’engagement. Si le client en vient à considérer l'IA comme un produit, il finira par se demander pourquoi il a besoin de moi : l'IA est là, elle produit des résultats, il pourrait simplement l'exécuter lui-même. Si l'évaluation concerne le produit, l'IA est un outil que j'utilise pour effectuer le travail d'évaluation plus efficacement ; l'engagement porte sur mon jugement, augmenté par la machinerie, et non sur la machine elle-même. Le premier argument est celui que vous finissez par perdre ; ce dernier est stable.

Évaluez la révision, pas la génération. Proposez des sélections organisées, pas des dumps. Encadrez l’engagement autour d’un jugement augmenté par des machines, et non de machines qui rendent le jugement obsolète. C'est le moment facturable ; c'est l'engagement durable.

Conversion d'un PoC

La validation de principe est terminée, elle s'est bien déroulée et la question se pose désormais de savoir si l'engagement se poursuivra sur quelque chose de plus long. Ce chapitre porte sur la conversion – les mécanismes spécifiques permettant de transformer une PoC réussie en une relation continue – car laisser cette transition au hasard est la façon dont de nombreuses bonnes PoC se terminent sans devenir autre chose.

Le moment où la PoC se termine est le moment où la conversation sur « la suite » doit avoir lieu, ou cela n'a pas lieu. Si je laisse s'écouler quelques semaines entre la livraison du PoC et la proposition de l'étape suivante, l'énergie s'estompe, d'autres priorités attirent l'attention du client et la conversation d'extension devient quelque chose que les deux parties doivent relancer à froid. Ma règle est désormais d'ouvrir la conversation sur l'étape suivante avant l'arrivée du livrable final du PoC - lors de l'examen du dernier artefact, pas après - afin que l'élan de l'examen se reflète directement dans la planification de la suite.

La forme de la proposition de conversion est importante et j'ai appris que la spécificité l'emporte sur le caractère facultatif. Plutôt que de présenter un menu de prochains engagements possibles et de demander au client de choisir, je recommande une prochaine étape spécifique – une forme, un prix, une durée – et je le laisse accepter, refuser ou contrer. Les menus créent une paralysie des décisions ; une recommandation spécifique crée une décision spécifique, et ce sont les décisions spécifiques qui sont réellement prises. S’ils veulent une forme différente, ils me le diront, et maintenant nous négocions une alternative concrète plutôt que d’examiner des options.

Ce que devrait être la prochaine étape spécifique varie selon le résultat de la PoC, mais il existe une heuristique : la prochaine étape devrait répondre à la question naturelle que la PoC vient de soulever. Si le PoC prouve qu'une forme fonctionne, l'étape suivante consiste à transformer la forme en quelque chose sur lequel le client peut réellement compter. Si le PoC prouve l’existence d’un marché pour une capacité, l’étape suivante consiste à développer cette capacité à grande échelle. Si le PoC soulève une nouvelle question que le client ne se posait pas auparavant, l'étape suivante pourrait être un deuxième PoC sur cette nouvelle question. Dans tous les cas, la prochaine étape est une extension spécifique de ce que le PoC vient de découvrir, et non un générique « continuer à travailler ensemble ».

La conversation sur la tarification de la conversion est différente de la tarification du PoC (Chapitre 34), car le PoC a effectué l’essentiel du travail d’établissement de la confiance. Le client sait comment je travaille maintenant ; Je sais à quoi ressemble leur environnement ; les deux parties disposent de preuves concrètes quant à la pertinence de poursuivre leur engagement. Les prix de l’engagement continu peuvent et doivent être proportionnels à la valeur réelle, et non à un prix filtré comme l’était le PoC. Sous-facturer lors de la conversion est une erreur courante : les praticiens sont tellement reconnaissants que le client veuille continuer qu'ils fixent un taux permanent faible. Le PoC était le filtre ; la conversion est l'endroit où vous gagnez un tarif professionnel équitable.

Il existe un scénario qui mérite d’être évoqué, celui du PoC qui ne s’est pas bien passé. Parfois, la preuve de concept prouve que le concept ne fonctionne pas, ou que la forme doit changer fondamentalement, ou que le problème réel du client est différent de ce qu'il a décrit. Dans chaque cas, la démarche honnête consiste à le dire et à proposer une prochaine étape redirigée ou à se séparer gracieusement. Réussir une conversion à partir d'un PoC raté est la façon dont naissent les engagements à long terme ; échouer gracieusement est la façon dont vous êtes référé à un client qui vous convient mieux.

Ouvrez la conversation de l'étape suivante pendant que l'élan est en direct. Proposez une forme spécifique, pas un menu. Évaluez l’extension en fonction de sa valeur, et non en tant que filtre. Et lorsque le PoC n’a pas obtenu de prolongation, dites-le honnêtement. La conversion est un moment qui atterrit ou se dissipe ; traitez-le comme un livrable de premier ordre du PoC lui-même.

La spécification des 30 premiers jours

Chaque engagement continu commence par trente premiers jours, et le fait de bien respecter ces trente jours détermine la forme de tout ce qui suit. J'écris un document spécifique pour cette phase - la spécification des 30 premiers jours - car l'ambiguïté au cours du mois d'ouverture devient très coûteuse et très rapide, et une spécification écrite est le moyen le moins cher de compresser cette ambiguïté en décisions convenues.

Les spécifications des 30 premiers jours répondent à un petit ensemble de questions délibérées. Quel résultat visons-nous pour ce premier mois ? Quel livrable existera au trente jour qui n’existait pas au premier jour ? Du côté du client, qui est l'interlocuteur unique ? Quelle est la cadence des mises à jour et des avis ? Quel est le budget pour cette phase, en argent et en heures ? Que se passe-t-il au trenteième jour : y a-t-il une suite prévue, une révision, une fin naturelle ?

La raison pour laquelle j’insiste pour écrire cela, dans des phrases ordinaires plutôt que dans un modèle de plan de projet, est que les mots écrits sont l’artefact vers lequel les deux parties peuvent pointer lorsqu’un malentendu surgit. Les accords verbaux sur la portée sont mal mémorisés en quelques semaines, non pas parce que l'une ou l'autre des parties est malhonnête, mais parce que la mémoire humaine reconstruit les conversations différemment pour différents besoins. Une spécification écrite supprime cette reconstruction – soit elle indique X, soit elle ne le fait pas, et les deux parties examinent les mêmes preuves.

La clause du point de contact unique mérite sa propre défense car c'est celle qui, selon moi, compte le plus. Lorsqu'un engagement client compte trois ou quatre parties prenantes qui peuvent diriger mon travail, les priorités deviennent incohérentes - une personne me dit que la priorité est X, une autre dit Y, une troisième m'entraîne vers Z - et je finis par supporter le coût de coordination pour résoudre des contradictions qui n'existent que parce que le client ne les a pas résolues en interne. Un seul point de contact règle le problème à la source : il détient la priorité, il résout les désaccords internes et je dispose d'une voix cohérente contre laquelle travailler. Il ne s'agit pas d'un mouvement de contrôle ; c'est la gestion de projet du client qui arrive à temps.

La question du trenteième jour est la question que les praticiens sautent le plus souvent et sur laquelle j'insiste maintenant. Que se passe-t-il à la fin des trente premiers jours ? Idéalement, il s’agirait d’une réunion d’examen spécifique au cours de laquelle les deux parties examineraient ce qui a été livré par rapport à ce qui avait été promis et décideraient ensemble s’il convient de poursuivre, d’ajuster ou de mettre fin au projet. Sans cette réunion programmée à l’avance, l’engagement dérive jusqu’au deuxième mois sur l’inertie, et l’inertie n’est pas la même chose qu’une poursuite éclairée. La réservation de l'examen du trentenaire dans le cadre de la spécification initiale oblige à un enregistrement délibéré qui garantit l'honnêteté des engagements.

La spécification nomme également explicitement ce qui est hors de portée pendant ces trente jours. Pas tout ce que le client pourrait souhaiter ; pas la future feuille de route ambitieuse ; c'est juste le résultat spécifique de ce mois-ci. Les éléments hors de portée sont classés comme candidats pour les phases futures, et tout le monde sait qu'ils ne font pas partie de ce que nous construisons actuellement. C'est l'antidote à la dérive de portée que le chapitre 58 abordera en détail : il n'empêche pas la dérive, mais il rend la dérive visible et négociable plutôt que silencieuse et unilatérale.

Écrivez-le. Répondez au petit ensemble de questions spécifiques. Nommez le point de contact. Réservez la revue du jour trente. Dites ce qui est hors de portée. Trente jours planifiés ont tendance à produire des mois deux et trois qui en valent la peine.

L'échelle de confiance

La confiance dans une relation client n'est pas un état unique : c'est une échelle avec des échelons distincts, et la position d'un client sur cette échelle détermine à quoi il dira oui et à quoi il reculera. Comprendre les échelons et les gravir délibérément plutôt que de supposer que la confiance est présente alors qu'elle ne l'est pas, c'est ce qui transforme les engagements ponctuels en engagements durables.

L’échelon inférieur est plus étrange. Le client a entendu parler de vous, a peut-être vu votre travail et envisage d’avoir la première conversation. Ils évaluent si vous êtes suffisamment compétent pour valoir leur temps. À cet échelon, vous êtes un candidat et non un partenaire. Ce que vous dites compte moins que ce que vous démontrez : un portfolio, une étude de cas, un exemple spécifique qui correspond à leur problème. À ce niveau, la confiance se construit sur des preuves et non sur des affirmations.

L’échelon suivant est celui de l’acheteur PoC. Ils ont décidé d'acheter une petite preuve de concept contenue. Désormais, ils évaluent non seulement les compétences, mais aussi le style de travail, la communication et si le partenariat sera confortable. Cet échelon teste spécifiquement la fiabilité à petite échelle : fournissez-vous ce que vous avez dit, quand vous l'avez dit, sous la forme que vous avez dite. Chaque petite promesse tenue les fait progresser ; chaque petite promesse non tenue les fait descendre, plus rapidement que la taille de la promesse ne le suggère.

L'échelon supérieur est celui des membres de la liste. Le PoC s’est converti ; vous bénéficiez d'un engagement mensuel ou d'un engagement continu. Désormais, ils évaluent non seulement la fiabilité, mais aussi le jugement : parvenez-vous à détecter des choses qu'ils auraient manquées, à orienter le travail dans des directions auxquelles ils n'auraient pas pensé, à leur faciliter la vie d'une manière qu'ils ne peuvent pas exprimer mais qu'ils peuvent ressentir. Cet échelon teste la valeur au-delà de l'exécution, et les clients de cet échelon sont ceux pour lesquels l'engagement devient stratégique plutôt que transactionnel.

L’échelon supérieur est celui du conseiller de confiance. La relation a franchi un seuil où le client vous pose des questions sur des problèmes qui sortent du strict cadre de la mission, car votre jugement lui-même fait désormais partie de ce qu'il achète. À cet échelon, vous ne vous contentez pas de livrer ce pour quoi vous avez été embauché ; vous êtes une voix qu'ils consultent sur des décisions adjacentes, parfois sur des décisions bien en dehors de votre domaine d'origine. Il faut des années pour obtenir le statut de conseiller de confiance et peut être perdu en un après-midi en donnant des conseils qui s'avèrent erronés sur un sujet sur lequel vous n'auriez pas dû donner votre avis.

L'erreur que je constate le plus souvent est de traiter un client comme étant plus haut dans l'échelle qu'il ne l'est réellement et d'être surpris lorsqu'il n'agit pas comme tel. Un acheteur PoC n’acceptera pas une recommandation stratégique comme le ferait un conseiller de confiance ; ils l'entendront comme une dérive ou comme de l'arrogance. Un membre de la liste ne signera pas un nouvel engagement important lors d'un appel téléphonique comme le ferait un conseiller de confiance. Chaque échelon a son plafond sur ce qu'un client acceptera, et dépasser ce plafond avant que l'échelon ne soit gagné nuit à l'ensemble de la relation. Lisez correctement l'échelon et calibrez en conséquence.

Il existe une erreur inverse, qui consiste à sous-traiter un conseiller de confiance en le considérant comme un simple membre de la liste. Lorsqu'un client a effectivement atteint l'échelon supérieur, le traiter comme un travail que vous entretenez plutôt que comme une relation que vous dirigez semble dédaigneux et il se désengagera progressivement. Reconnaître quand une relation s’est améliorée est aussi important que reconnaître quand ce n’est pas le cas.

Sachez à quel échelon se trouve un client. Déplacez-vous délibérément vers le haut. N'allez pas trop loin ; ne sous-traitez pas. La confiance se gagne par étapes spécifiques et se perd par étapes non spécifiques.

Dérive de la portée

Chaque engagement dérivera, et la dérive n’est pas le problème ; une dérive inavouée l’est. La dérive de la portée est l'éloignement lent et cumulatif du travail par rapport à ce qui avait été initialement convenu, et cela se produit dans tout projet réel parce que la réalité ne respecte pas les spécifications initiales. La discipline n’est pas d’empêcher la dérive – c’est futile – mais de la rendre visible et négociée au fur et à mesure qu’elle se produit.

Le mécanisme de dérive est petit et progressif. Lors d'une conversation du mercredi, le client mentionne « oh, pourrions-nous aussi… » et je dis oui, et l'ajout semble trivial dans son contexte. La semaine prochaine, encore un petit ajout. La semaine d'après, un de plus. Individuellement, aucun d’entre eux ne justifie une conversation sur la portée. Collectivement, ils aboutissent à une refonte substantielle de ce que l’engagement apporte, et au moment où le total est visible, les deux parties ont discrètement convenu d’un projet différent sans jamais avoir nommé le changement.

Le mode d’échec n’est pas la dérive elle-même – c’est le fait que les deux parties oublient la portée initiale. J'ai participé à des missions au cours desquelles, quatre mois plus tard, le client nous a demandé quand nous allions livrer quelque chose qui était conforme aux spécifications d'origine, et j'ai réalisé que nous avions tous les deux laissé les ajouts à la dérive le retirer du plan sans reconnaître que quelque chose avait changé. Personne n’était contrarié, mais personne n’était clair non plus, et l’ambiguïté a englouti une semaine de réalignement que nous n’aurions pas dû consacrer. Cette dérive sans nom est devenue une dette qui a dû être payée exactement au mauvais moment.

La discipline qui résout ce problème est petite et peu coûteuse : chaque fois qu'un « oh, pourrions-nous aussi » arrive, je l'appelle comme un changement de portée, sur place, dans l'instant. Pas comme une objection – comme une reconnaissance factuelle. "Oui, nous pouvons ajouter cela ; en le notant comme un changement dans le plan, ce qui signifie que X et Y par rapport à l'original deviennent la cinquième semaine au lieu de la troisième." L’ajout est le bienvenu ; la dénomination est ce qui permet aux deux parties de conserver la même image de ce qui est livré. Une fois que la conversation sur la portée est une habitude de cinq secondes, elle cesse de paraître gênante et fait partie du fonctionnement de l'engagement.

Il existe un piège spécifique pour les missions d’IA que le conseil traditionnel n’a pas de manière aussi précise. Étant donné que le travail natif de l’IA peut produire de nouvelles capacités à moindre coût, les clients ajoutent souvent des fonctionnalités en partant du principe que « l’IA peut tout simplement le faire ». Parfois, ils ont raison et l’ajout est vraiment trivial. Parfois, ils se trompent et l’ajout nécessite une nouvelle plomberie significative. Le client ne peut pas faire la différence de l'extérieur, c'est donc mon travail de lever l'ambiguïté — de dire honnêtement si une demande est triviale, modérée ou substantielle, et de fixer le prix et de planifier en conséquence. La sous-facturation des requêtes « ajoutez simplement » parce qu'elles semblent petites est l'un des moyens les plus courants de perdre de la marge dans le travail d'IA.

The corollary is that not all drift is bad. Une certaine dérive est l'adaptation de l'engagement à ce dont le client a réellement besoin, par opposition à ce dont il pensait avoir besoin au départ. Refuser de dériver du tout – en insistant de manière rigide sur les spécifications initiales – est un moyen de livrer exactement la mauvaise chose, exactement dans les délais. Le but n'est pas la stase ; it's negotiated evolution. Acknowledge, price, reschedule; puis adaptez-vous.

Name every drift the moment it arrives. Évaluez-le honnêtement. Renégociez le plan. Adaptez-vous délibérément. Silent drift is the failure mode; la dérive délibérée est l’engagement qui fait son travail.

Le test « Encore une chose »

Il y a un petit test que j'effectue à la fin de chaque conversation avec un client, et il a permis d'enregistrer plus d'engagements que n'importe quelle autre discipline plus large de ce livre. J'appelle cela le test d'une chose de plus : avant de raccrocher, je demande à voix haute : "Y a-t-il autre chose en tête que nous n'avons pas abordé ?" La question est triviale. Les réponses, cumulées au fil des années, ont façonné mon équipe plus que n'importe quelle décision stratégique que j'ai prise.

La raison pour laquelle cette question est importante est que les clients ont souvent des préoccupations qu'ils n'avaient pas prévu de soulever. Quelque chose les dérangeait depuis le début de la semaine. Le commentaire d’un collègue qui est resté. Une petite inquiétude sur la direction des travaux. Aucun d’entre eux n’est assez important pour être évoqué sans y être invité – ils donneraient l’impression d’être harcelants ou excessifs. Mais étant donné une ouverture spécifique, la plupart des clients les nommeront, et une fois nommés, ils pourront être traités alors qu'ils sont petits plutôt qu'après qu'ils soient devenus un véritable problème.

Le mode d’échec du fait de ne pas poser de questions est que ces préoccupations non soulevées s’aggravent. Les petites angoisses deviennent de plus grandes angoisses. Les problèmes tacites se transforment en relations discrètement effilochées. Finalement, soit le client en parle lorsqu'il est devenu quelque chose qui nécessite une conversation difficile, soit – pire – il se désengage silencieusement, parce qu'il ne se sent pas entendu sur les petites choses. Les deux résultats sont évitables, et l’évitement consiste en une question de trente-deuxièmes à la fin de la réunion.

Ce que j'ai appris à faire avec les réponses compte autant que la question. Quand quelque chose fait surface, je le prends au sérieux, lors de cette réunion, sans différer ni minimiser. Même si le problème est mineur, le fait d'y répondre sur le moment indique que les observations mineures du client méritent attention, ce qui le rend alors plus susceptible de soulever la suivante, qui est la boucle que je souhaite. L'alternative – « laissons cela de côté et parlons-en la prochaine fois » – enseigne aux clients que les petites préoccupations ne valent pas la peine d'être soulevées, et j'arrête d'entendre parler de problèmes alors qu'ils sont encore petits.

Le test est également utile dans le sens inverse, en tant que discipline pour moi. Avant la fin de la réunion, je me demande – en silence – y a-t-il quelque chose que j'ai retenu ? Quelque chose que j'ai remarqué cette semaine et que j'ai décidé de ne pas mentionner. Quelque chose qu'un collègue a dit à propos du travail du client et qui semblait difficile à évoquer. Même principe : il est moins coûteux d'en parler maintenant que de le faire évoluer plus tard vers une conversation différée. Le test d’une chose de plus s’applique dans les deux sens.

Il y a un point philosophique plus important à cela, à savoir que le mode maintenance est un mensonge que les clients reconnaissent. Les engagements qui se résument à « nous ne faisons que faire la chose » sans ouvertures périodiques permettant aux deux parties d'exprimer leurs préoccupations pourrissent tranquillement, parce que la réalité ne cesse de changer et que l'espace permettant de reconnaître ces changements a été fermé. La question supplémentaire est un petit acte structurel visant à maintenir cet espace ouvert, réunion après réunion, sans nécessiter une rétrospective spéciale ou un examen formel pour le justifier.

Demandez à chaque réunion s'il y a autre chose. Abordez ce qui fait surface sur le moment. Faites le même autocontrôle de votre côté. De petites ouvertures, constamment entretenues, permettent aux relations de rester honnêtes – et les relations honnêtes sont celles qui survivent à la dérive, à la facture surprise, à l’examen maladroit du trentenaire et à tout ce qui autrement les éroderait.

Clients de référence

La sixième partie se termine sur l’atout spécifique qui transforme une pratique compétente en une pratique auto-entretenue : les clients de référence. Ce sont les clients dont les engagements se sont suffisamment bien déroulés et dont la relation avec moi est suffisamment solide pour qu'ils recommandent activement de nouveaux prospects, prennent des appels de référence et laissent leur histoire faire partie de ma conversation commerciale. Construire un banc de clients de référence n’est pas une chose agréable – c’est l’infrastructure marketing qui permet à tout le reste d’arrêter d’être une vente à froid.

Le mécanisme par lequel les clients de référence comptent s’aggrave. De nouveaux prospects entendent parler de moi grâce à la présentation chaleureuse d'un client existant. Ils arrivent à la découverte en ayant déjà confiance dans les grandes lignes de ce que je fais, parce que quelqu'un en qui ils ont confiance le leur a dit. Les taux de conversion des prospects référés chaleureusement sont considérablement plus élevés que ceux des prospects froids, et les engagements sont plus sains car les deux parties commencent plus haut dans l'échelle de confiance du chapitre 57. Chaque client de référence est un atout composé, produisant plus de clients dont les engagements ont plus de chances de réussir.

Ce qui fait d'un client un client de référence n'est pas le résultat d'un seul engagement, c'est la forme globale de la relation. Les clients de référence ont généralement trois propriétés : l'engagement a résolu un vrai problème pour eux et ils peuvent le dire spécifiquement, la relation de travail était suffisamment agréable pour qu'ils recommencent volontairement, et je suis resté en contact depuis la fin de l'engagement (ou au milieu d'un engagement en cours), donc je ne demande pas de faveur à quelqu'un qui a oublié mon existence. N'importe lequel des trois sans les autres produit une référence plus faible.

L’action qui en découle est que le développement d’un client de référence est une habitude et non un plan. Rester en contact signifie des enregistrements occasionnels - pas des poussées de ventes, de véritables messages "comment ça se passe, je pensais que vous pourriez trouver cela intéressant" suffisamment espacés pour donner l'impression d'être une considération plutôt qu'une poursuite. Une fois par trimestre est à peu près convenable pour la plupart ; cela ressemble plus souvent à un ping de maintenance, moins souvent à une disparition. Le fait est que lorsque l’appel de référence d’un prospect arrive, le client est suffisamment chaleureux pour le recevoir et connaît suffisamment mon travail actuel pour en parler avec précision.

Le mode d'échec consiste à traiter les références comme une relation à sens unique : les demander sans rien rendre. Les appels de référence prennent du temps au client. Les présentations chaleureuses brûlent une petite partie du capital social du client avec le prospect. S'assurer que l'échange est véritablement bidirectionnel – que je leur envoie des références lorsque je le peux, que je partage du matériel pertinent avec eux, que je leur suis utile d'une manière qui ne concerne pas ma propre entreprise – est ce qui maintient la relation de référence saine au fil des années. L’exploitation minière de référence extractive épuise rapidement un banc ; composés de construction de référence réciproques.

Il y a un mouvement spécifique qui mérite d'être nommé, c'est la demande gracieuse. Lorsqu'un prospect se présente et que j'aimerais acheminer via un appel de référence avec un client existant, je demande d'abord clairement au client s'il serait prêt à répondre à un appel spécifique pour une raison spécifique. Pas une couverture générale « seriez-vous une référence en général » – c'est plus facile de dire non et cela crée une obligation d'antécédents. Une demande spécifique avec une occasion précise respecte le temps du client et lui permet de dire non clairement si ce n'est pas le bon moment. La plupart disent oui ; ceux qui ne restent pas au chaud parce que je n'en ai pas trop demandé.

Résolvez de vrais problèmes. Rendre la relation agréable. Rester en contact. Réciproquez la valeur. Demandez gracieusement. Une douzaine de véritables clients de référence constituent un moteur marketing que vous n'avez pas besoin de maintenir, car ils le maintiennent pour vous – une introduction chaleureuse à la fois.

Le grattoir que j'ai refusé

Le client était sérieux, le budget était réel, le travail technique était simple. Scrapez un grand site tiers, exécutez son contenu via un modèle, publiez des versions digérées sur leur plateforme. Sur le papier, il s’agissait d’un engagement de deux semaines avec des honoraires intéressants. Et j'ai dit non, et c'était l'une des meilleures décisions commerciales que j'ai prises, et je veux consacrer un chapitre à expliquer pourquoi, car le raisonnement compte plus que le résultat.

Le problème n'était pas technique. Construire le grattoir aurait pris un après-midi. L'intégration du modèle était routinière. Le côté publication était standard. Rien dans la mécanique n'était difficile, et si la mécanique avait été le tableau d'ensemble, j'aurais dit oui et j'aurais eu une belle facture à envoyer dans deux semaines. Ce que je ne pouvais pas dépasser, c'était les conditions de service – à la fois celles de la source et celles du fournisseur modèle – que l'ensemble de l'accord devait violer pour fonctionner.

Les conditions d’utilisation du site source interdisaient explicitement le scraping et la republication automatisés. Les conditions de service du fournisseur de modèles voyaient d'un mauvais oeil l'alimentation de contenu tiers récupéré et republié via leur API. Ni l’un ni l’autre n’était ambigu. Les deux étaient le genre de clause que vous pouvez consulter directement, sur la page du fournisseur, et toujours vous convaincre qu'elles ne s'appliqueront pas dans votre cas spécifique - parce que l'application est retardée, le rayon d'explosion est petit au quotidien et d'autres personnes font des choses similaires sans punition visible.

Le raisonnement que j’ai suivi dans ma tête mérite d’être expliqué, car c’est le même raisonnement que j’applique maintenant à tout engagement limite. L'avantage était deux semaines d'honoraires, un client satisfait et une étude de cas que je pouvais citer. L’inconvénient, si l’application arrivait, était la fermeture du compte modèle – qui est le même compte sur lequel s’appuient tous mes autres clients. Mon risque personnel était proportionné à l’engagement ; mon risque professionnel était proportionné à l’ensemble de mon entreprise, car l’actif puni serait celui dont dépendait chaque client. Répartition asymétrique des risques.

Quand j’ai dit non, le client a été surpris, puis curieux, puis effectivement respectueux. Ils m'ont demandé si je pouvais recommander quelqu'un d'autre, et j'ai répondu non, car celui qui accepterait le poste finirait par payer le même prix, simplement à partir d'un compte différent. Ils ont quand même trouvé quelqu’un ; que quelqu'un d'autre a géré l'accord pendant environ huit mois avant la fermeture de son compte de fournisseur modèle, après quoi le client a dû dénouer une opération de huit mois dans un bref délai. Pendant ce temps, mon compte fournisseur est resté ouvert et mes autres clients n'ont pas connu de panne causée par un engagement sans rapport.

La leçon n’est pas que les documents ToS sont toujours sacrés ; c'est que la répartition des risques des engagements limites est asymétrique, ce qui est facile à mal interpréter. Petit avantage, grand inconvénient différé, l’inconvénient tombe sur une ressource dont dépendent tous mes clients. Tout engagement dans cette forme est une mauvaise transaction, même lorsque la probabilité spécifique d'application est faible. Je refuse maintenant tout ce qui prend cette forme sans une longue délibération – la réponse est non, et la conversation honnête est courte, et les deux parties avancent rapidement.

Dites non tôt. Dites non clairement. Ne recommandez pas le travail à quelqu'un d'autre. L’engagement que vous avez refusé est le compte que vous avez tenu, et ce compte vaut bien plus que n’importe quel frais.

Le Billing Cliff que j'ai attrapé une semaine

Une semaine avant, un changement de facturation aurait augmenté mes coûts d'environ quarante pour cent du côté sans tête de la flotte, j'ai remarqué. Je ne veux pas exagérer – je n’ai pas eu un moment héroïque de perspicacité ; J'avais un rapprochement mensuel ennuyeux et un paragraphe dans les notes de version d'un fournisseur que la plupart de mes pairs n'avaient apparemment pas lu. La raison pour laquelle la semaine d’avertissement est importante est qu’une semaine suffit pour renégocier ; un jour ne l'est pas ; et le découvrir via la facture, c'est le découvrir trop tard pour faire quoi que ce soit.

Ce qui a déclenché le piège, c'est le rituel du chapitre 40 – le rapprochement de fin de mois qui, au cours de l'année précédente, m'avait appris à quoi ressemblait le « normal » sur la facture de chaque fournisseur. Lorsque je me suis assis ce lundi pour réconcilier le mois précédent, les chiffres correspondaient, mais les notes de publication du mois à venir contenaient un changement dans la structure de mesure qui aurait discrètement remodelé mes coûts. Pas une annonce de gros titre « nous augmentons les prix » ; une clarification technique sur la façon dont un pool spécifique allait être mesuré, nichée dans un paragraphe que la plupart des gens auraient survolé. Le changement a été écrit pour ne pas être alarmant, et si je n'avais pas lu attentivement depuis le siège de la réconciliation, je l'aurais également survolé.

La semaine qui suivit fut la partie utile. Parce que je l’avais détecté tôt, j’ai pu réfléchir calmement à la réponse. Le changement affecterait-il tous mes clients de la même manière, ou seulement certains ? Quel a été l’impact total sur mes prévisions ? Cela valait-il la peine de le transmettre aux clients, de l'absorber ou de le restructurer ? Quels clients devaient être informés immédiatement, lesquels pouvaient attendre le prochain examen programmé ? J'ai pris des décisions avec le temps de réflexion, et ces décisions se sont avérées nettement meilleures que celles que j'aurais prises sous la pression d'une facture choc le mois suivant.

La décision tactique spécifique que j'ai prise a consisté à déplacer certains des flux de travail concernés vers un autre pool que le changement n'a pas touché, ce qui a atténué l'essentiel de l'impact. Ce n'est pas quelque chose que j'aurais pu faire au moment de la facturation, car à ce moment-là, les modèles d'exécution étaient déjà établis et la configuration du pool alternatif aurait pris du temps. Un avertissement préalable m'a offert l'option d'une restructuration, ce qui a transformé un impact de quarante pour cent en quelque chose de plus proche d'un impact de cinq pour cent. Les cinq pour cent que j’ai absorbés ; il ne fallait rien dire de difficile à personne.

La leçon n’est pas que les notes de version sont importantes, même si elles le sont. La leçon est que la discipline du rapprochement mensuel ne consiste pas seulement à faire correspondre les chiffres, il s'agit de construire le modèle mental de votre fournisseur qui permet de détecter des changements subtils. Les praticiens qui ne font pas de rapprochement ne peuvent pas faire la distinction entre « les chiffres ont bougé parce que l'usage a changé » et « les chiffres ont bougé parce que le compteur a bougé », et cette incapacité fait que chaque changement de prix est une surprise. La réconciliation construit l'intuition ; l'intuition capte les changements ; les captures permettent de gagner du temps pour répondre.

Il y a une leçon plus large sur la vigilance que je souhaite énoncer clairement. Dans cette industrie, le sol sous vos pieds est véritablement en mouvement, et le mouvement est souvent communiqué d'une manière qui suppose que vous y prêtez une attention particulière. Si vous n’y prêtez pas attention, vous découvrirez le mouvement à vos dépens. Les gens qui n’y prêtent pas attention ne sont pas paresseux – ils donnent la priorité à d’autres choses – mais le coût de cette priorisation est qu’un mauvais trimestre arrive sans avertissement, et au moment où vous vous en rendez compte, l’espace pour réagir s’est fermé.

Lisez les notes de version. Faites les rapprochements. Développez l’intuition. Une semaine d’avertissement, ce n’est pas beaucoup ; c'est bien plus que rien.

Le coup d'envoi de la charité

L’un des engagements les plus instructifs que j’ai jamais fait était pour une petite association caritative qui avait à peine les moyens de me payer. Le salaire était minime, l’ambition était démesurée et le résultat a été livré en six semaines – une infrastructure qui a considérablement modifié leur façon de fonctionner. Cela m’a appris des choses sur la façon de travailler sous de réelles contraintes qu’aucun engagement bien financé n’aurait jamais pu avoir.

Le coup d’envoi ressemblait, sur le papier, au début d’une catastrophe. L'organisation avait besoin d'un système qui aurait pris environ six mois à une équipe logicielle de taille moyenne aux tarifs de conseil ordinaires. Leur budget représentait environ un dixième de ce montant. Chaque instinct disait de s'éloigner. Je ne l'ai pas fait, en partie parce que la mission comptait pour moi personnellement, et en partie parce que je voulais voir si le modèle décrit dans les chapitres précédents – restructuration de type Fusion, travail machine du jour au lendemain, examen humain rigoureux – pouvait réellement produire un résultat aussi important avec un budget aussi petit. C’était, en ce sens, ma propre expérience autant que leur projet.

La restructuration qui a permis son fonctionnement mérite d’être évoquée. Il n'y aurait pas d'équipe de six personnes ; il y avait moi et un contributeur à temps partiel de leur côté. Il n'y aurait pas de délai de six mois; il y avait une fenêtre difficile de six semaines parce que le moment opérationnel pour lequel ils avaient besoin du système était calendé et non négociable. Chaque abstraction, chaque fonctionnalité "nous pourrions aussi vouloir...", chacune de mes préférences internes a été supprimée dès le premier passage. Ce qui a survécu était le plus petit système possible qui répondrait à leur vraie question – rien de plus, et livré comme un artefact clair plutôt que comme une suite de composants.

L'équipe de nuit effectuait les travaux mécaniques. Chaque nuit, des lots de génération s'exécutaient sans surveillance (contenu, structure, intégrations) laissant des traces que je pouvais consulter le matin. Mes heures étaient presque entièrement consacrées à la révision et à la spécification, pas à la saisie. Dans le cadre d'une mission de conseil normale, j'aurais passé quarante heures par semaine à construire ; sur celui-ci, j'ai passé peut-être six heures par semaine à réviser et huit heures par semaine à rencontrer le client. Le reste s'est produit pendant que je dormais, en leur nom, à un coût marginal suffisamment faible pour que le budget puisse se le permettre.

La leçon qui m’a le plus surpris concernait la portée. Chaque fonctionnalité que nous avons supprimée dès le premier passage, nous l'avons coupée de façon permanente – et aucune d'entre elles n'a été oubliée. Le système a été livré sans le deuxième niveau de fonctionnalités qui auraient semblé essentielles dans une version bien financée, et les utilisateurs n'ont pas posé de questions à leur sujet. Ce qui compte, lorsque la contrainte est réelle, est un sous-ensemble plus restreint de ce que les praticiens pensent important. La contrainte agit comme un sérum de vérité sur lequel les traits méritent effectivement leur place.

L’autre leçon concernait la satisfaction des clients et la fausse corrélation entre budget et plaisir. L'association caritative était plus ravie du résultat que la plupart de mes clients bien financés, car nous avions véritablement résolu leur problème dans les limites qu'ils m'avaient imposées. L’inadéquation entre ce à quoi ils s’attendaient – ​​probablement une version de qualité réduite d’un engagement normal – et ce qu’ils ont obtenu – une petite chose de forme spécifique qui répondait pleinement à leurs besoins – a créé un écart positif qu’aucun engagement coûteux n’aurait pu ouvrir. Le plaisir réside dans l’écart entre les attentes et la livraison, et les engagements bon marché présentent parfois le plus grand écart disponible.

Je fais désormais confiance à la conclusion généralisée : lorsque la contrainte est réelle, respectez-la structurellement, et non en vous attaquant plus durement à un mauvais plan. Le modèle Fusion du chapitre 52 est la bonne réponse à une véritable pénurie ; rien de moins, c'est simplement faire le travail normal à prix réduit. Et la machine, bien utilisée, peut produire des résultats à des prix qui seraient impossibles à atteindre pour une opération purement humaine. C'est tout l'intérêt d'apprendre à travailler de cette façon.

Le système d'exploitation visuel que j'ai réduit à trois deltas

Un client est arrivé avec une spécification de vingt pages décrivant ce qu'il appelle un « système d'exploitation à agent visuel ». Panels, tableaux de bord, orchestrateurs, intégrations, agents gérant les agents. C'était ambitieux dans le sens que le mot signifie habituellement : il voulait être beaucoup de choses, dont aucune n'était encore définie avec précision, et toute la forme allait changer au contact de la réalité. Mon travail, pensaient-ils, consistait à élaborer les spécifications. Il s'est avéré que mon travail consistait à réduire les spécifications à quelque chose qui valait la peine d'être construit.

La première conversation a été difficile car je devais dire – gentiment mais clairement – ​​que telle qu'elle était écrite, la spécification produirait une preuve de concept magnifiquement soignée et aucun résultat commercial réel. Vingt pages de fonctionnalités ne constituent pas un produit ; ils constituent une démo qui impressionne la personne qui a signé les vingt pages. Ce que j’ai proposé à la place était de passer la première semaine non pas à construire mais à réduire : identifier les trois deltas spécifiques – trois changements concrets par rapport à leur état actuel – qui apporteraient une valeur mesurable, et laisser tomber tout le reste de la feuille de route initiale.

La conversation sur la réduction était le véritable travail de l’engagement. Ensemble, nous avons parcouru les spécifications et, pour chaque fonctionnalité, posé une question : si nous ne l'avions pas construit, les mesures opérationnelles du client évolueraient-elles moins que si nous le construisions ? La grande majorité des fonctionnalités ont échoué à ce test : elles étaient intéressantes, plausibles et non porteuses. Trois fonctionnalités ont été adoptées : un flux de travail spécifique que l'équipe effectuait manuellement et qu'un outil bien conçu pouvait automatiser ; une donnée spécifique qui, si elle était révélée, modifierait considérablement la façon dont une décision a été prise ; une intégration spécifique dont l'absence provoquait des frictions quotidiennes.

Ces trois deltas constituent la première phase de l’engagement. Pas le système d'exploitation visuel. Pas les panneaux. Pas les orchestrateurs qui gèrent les orchestrateurs. Trois changements précis et mesurables dans leur réalité opérationnelle. Le reste de la spécification de vingt pages a été déposé comme candidat pour les phases ultérieures, sous réserve que la première phase montre une valeur qui justifie la poursuite. Il ne s’agissait pas d’une excuse pour réduire les livraisons ; il était axé sur la portée, donc la livraison avait une chance d'avoir de l'importance.

Six semaines plus tard, les trois deltas étaient opérationnels. Tous les trois ont modifié les mesures qu'ils étaient censés modifier ; deux les ont déplacés plus que ce que le client avait prévu. L'engagement s'est étendu, mais l'extension n'était pas "maintenant, construisons le système d'exploitation visuel à partir de la spécification d'origine". Il s'agissait de trois deltas plus concrets identifiés avec la même discipline. Itérer sur la valeur réelle fournie par rapport aux mesures opérationnelles plutôt que d'essayer de construire un système imaginé dont la valeur était théorique.

La leçon porte sur ce que signifie réellement la « vision » dans un engagement client. Les spécifications de vingt pages de systèmes à grande échelle ne sont souvent pas une vision, mais de l'anxiété. Le client craint de manquer quelque chose d’important, alors il énumère tout ce à quoi il pense qui pourrait être important. La vraie vision, au sens utile du terme, est un petit nombre de paris spécifiques sur ce qui compte réellement, tenus avec suffisamment de conviction pour dire non au reste. Aider un client à trouver cette vision - ou l'apporter, s'il ne le peut pas - est un service de bien plus grande valeur que d'exécuter consciencieusement la liste d'anxiété avec laquelle il est entré.

Réduisez l’ambition à des deltas spécifiques. Construisez les deltas. Mesurez le mouvement. Itérez à partir d'une valeur réelle, et non à partir d'un système imaginé. C'est ainsi que l'ambition devient réalisation ; tout le reste reste un diaporama.

Eme année d'intronisation

Un mercredi à 3 heures du matin, mon téléphone m'a réveillé. Une exécution nocturne planifiée échouait à plusieurs reprises sur la source de données d'un client, et l'alerte de surveillance s'était intensifiée parce qu'elle échouait depuis deux heures d'affilée. J'ai passé les quatre-vingt-dix minutes suivantes à ma table de cuisine à déboguer en pyjama, et l'incident m'a appris plus sur la maturité opérationnelle que n'importe quel engagement en heures calmes.

Le problème technique réel était banal. Le client avait fait pivoter un identifiant API sans me le dire, l'adaptateur que j'avais construit utilisait l'ancien identifiant et chaque tentative d'authentification échouait avec un 401 indiquant que la logique de nouvelle tentative - suivant le chapitre 29 - était correctement classée comme terminal et avait arrêté de réessayer, mais pas avant de générer suffisamment de bruit de journal pour me biper. Le correctif, une fois que j'ai compris ce qui s'était passé, consistait à mettre à jour les informations d'identification dans mon magasin de configuration et à redémarrer le pipeline. Cinq minutes de frappe après quatre-vingt-dix minutes d'enquête.

Ce qui a rendu l'incident instructif, ce n'était pas la résolution technique mais tout ce qui l'entourait. L'alerte s'était déclenchée correctement, ce qui signifiait que la surveillance fonctionnait. La trace des exécutions échouées était suffisamment bien structurée pour que je puisse reconstruire ce qui s'était passé à froid - aucune reproduction en direct n'était nécessaire, ce qui importait à 3 heures du matin lorsque la reproduction en direct sur le système de production d'un client aurait de toute façon été une mauvaise décision. Le modèle de sous-processus du chapitre 22 signifiait que je pouvais réexécuter manuellement une seule étape ayant échoué, de manière isolée, pour confirmer mon hypothèse sur les informations d'identification sans toucher à quoi que ce soit d'autre dans le pipeline.

Honnêtement, la conversation du lendemain avec le client a été la plus utile. J'ai expliqué ce qui s'était passé sans détour : ils avaient alterné un identifiant sans me le dire, mon système l'avait remarqué, alerté et arrêté en toute sécurité : aucune donnée corrompue, aucune exécution partielle laissée en mauvais état, aucun dommage côté client. Ils se sont excusés et j’ai dit de ne pas le faire ; l’incident avait exercé exactement le filet de sécurité pour lequel l’engagement était conçu. Ce que nous avons convenu à la place était d'ajouter une entrée de calendrier partagée pour les rotations d'accréditations, afin que je sache qu'elles arrivaient et que je puisse pré-organiser la nouvelle accréditation plutôt que d'être bipée à 3 heures du matin.

La leçon que je souhaite citer explicitement est que la maturité opérationnelle ne se mesure pas par l'absence d'incidents, mais par la façon dont les incidents qui se produisent se déroulent. Chaque système fonctionnant depuis longtemps a des moments à 3 heures du matin ; la question est de savoir si ces moments produisent une corruption des données et des échecs face aux clients, ou s'ils produisent un ingénieur bipé, une trace propre, un correctif de cinq minutes et une conversation de suivi productive. Les disciplines défendues par ce livre – traces structurées, erreurs de frappe, réexécutions de sous-processus isolés, surveillance qui se déclenche correctement – ​​portent leurs fruits exactement à 3 heures du matin. Ils existent pour rendre les mauvais moments ennuyeux.

L’autre leçon concerne les petits accords opérationnels qui découlent des incidents. L'entrée de calendrier que nous avons ajoutée est triviale ; cela aurait également évité tout l’incident s’il avait existé auparavant. La plupart des incidents survenus à 3 heures du matin indiquent un petit accord manquant qui aurait pu les empêcher, et la conversation qui suit l'incident est le moment où ces accords sont naturellement conclus. Sauter la conversation parce que « le problème technique est résolu » laisse le prochain incident tout aussi probable que celui-ci ; l'avoir transforme l'incident en amélioration structurelle.

Concevoir pour la réalité de 3 heures du matin. Rendre les mauvais moments ennuyeux. Ayez la conversation de suivi. Chaque incident qui se termine par un petit nouvel accord est un incident qui a payé ses propres frais de scolarité.

La régression du modèle

Une compétence que j'utilisais avec succès depuis six mois a commencé à produire de moins bons résultats. Rien n'avait changé de mon côté : aucune mise à jour du code, aucune modification de l'adaptateur, aucune modification rapide. Le taux de réussite de la télémétrie du chapitre 49 a doucement chuté en trois semaines, passant de quatre-vingt-dix-sept pour cent à quatre-vingt-deux. La raison s'est avérée être une modification de la version du modèle du côté du fournisseur que les notes de version avaient décrite comme une amélioration et qui, pour la classe spécifique de tâche que mes compétences effectuaient, était en fait une régression.

L'histoire vaut la peine d'être racontée car les régressions de modèles constituent une catégorie de problèmes que le génie logiciel traditionnel n'a pas la forme à laquelle on pourrait s'attendre. Dans un logiciel classique, si mon code n'a pas changé et que l'environnement n'a pas changé, le comportement ne change pas. Dans le travail d'IA, le modèle est une dépendance active dont le comportement peut changer sous moi sans avertissement, car le fournisseur a mis à jour les poids, le routage ou les valeurs par défaut d'échantillonnage, et le taux de réussite de mes compétences est une chose probabiliste qui peut évoluer à mesure que le modèle bouge.

La façon dont j'ai remarqué était, avec satisfaction, exactement la façon dont j'étais censé remarquer : le résumé hebdomadaire de télémétrie a signalé une compétence dont le taux de réussite dérivait vers le bas sans cause évidente. Avant d'en avoir le résumé, ce type de problème se serait manifesté lorsqu'un client se plaignait, des mois après une lente dégradation. Avec le résumé, je l'ai remarqué au cours de la troisième semaine et j'ai eu une hypothèse spécifique à la quatrième semaine. L’instrumentation a gagné sa place ici au sens le plus littéral du terme : c’était la différence entre le contrôle réactif des dommages et l’enquête proactive.

L’enquête elle-même était intéressante car les régressions de modèles nécessitent un état d’esprit de diagnostic différent de celui des bogues logiciels. Je n'ai pas pu comprendre le comportement du modèle. Je n'ai pas pu inspecter son état intermédiaire. Ce que je pouvais faire, c'était construire une petite suite d'entrées représentatives, les exécuter avec le modèle actuel et, en utilisant la fonction d'épinglage de version du fournisseur, avec la version précédente, et comparer les sorties des deux. La différence entre ces analyses était la régression, rendue concrète et mesurable. Ce n’était pas ambigu ; c'était là dans les artefacts, côte à côte.

La résolution avait plusieurs options et je devais choisir. Je pouvais épingler indéfiniment mes compétences sur la version précédente du modèle, mais la version précédente devait devenir obsolète dans quelques mois. Je pouvais réécrire les invites de la compétence pour contourner le comportement du nouveau modèle, mais cela me donnait l'impression de lutter contre la marée. Ce que j'ai fait en réalité, c'est d'acheminer cette classe spécifique de tâches vers un modèle différent - un homologue de celui qui avait régressé, du même fournisseur, qui gérait la classe de tâches sans régression - et de classer la table de routage de la compétence d'origine pour qu'elle soit revisitée une fois que la nouvelle version du modèle aurait eu quelques semaines pour se stabiliser. Parfois, la solution consiste à bouger plutôt qu’à argumenter.

La leçon est que les dépendances des modèles doivent être traitées davantage comme un système mobile que comme un système fixe, et des pratiques spécifiques en découlent : épinglage de version là où elle est disponible pour un travail critique, flexibilité de routage afin qu'une tâche puisse être déplacée entre les modèles sans réécriture, et suffisamment patiente en matière de télémétrie pour remarquer une dérive au fil des semaines plutôt que de s'attendre à des plantages au fil des heures. Les modes de défaillance spécifiques à l'IA nécessitent une hygiène spécifique à l'IA, et le parallèle le plus proche dans les logiciels traditionnels est probablement les mises à niveau du système d'exploitation ou du runtime - une catégorie à laquelle la plupart des ingénieurs savent qu'il faut se méfier, appliquée ici à quelque chose qui change plus souvent et plus silencieusement.

Des régressions de modèles se produisent. Remarquez-les via la télémétrie. Diagnostiquez par comparaison côte à côte. Contournez-les lorsque cela est possible. Et acceptez, comme vérité de travail, que le modèle n'est pas une primitive stable : c'est un service dont le comportement évolue, et votre infrastructure doit être construite pour s'adapter à ce mouvement sans que vous vous en rendiez compte après coup.

L'invite de fuite

Une invite que j'avais soigneusement conçue pour un client - des heures d'itération, intégrées dans son produit, faisant partie de ce qui faisait fonctionner le produit - a fini par être capturée et partagée sur les réseaux sociaux par un utilisateur final qui avait trouvé un moyen de l'extraire grâce à la réponse du modèle. La capture d'écran a été vue environ dix mille fois avant que je la voie. L’invite n’était pas exactement secrète ; il n’était pas non plus censé être public. Ce chapitre porte sur la manière spécifique dont j'avais réfléchi à la confidentialité rapide et sur la façon dont cette réflexion était erronée.

Le modèle mental que j'avais utilisé jusqu'à ce moment-là était que les invites fonctionnaient derrière une limite : mon serveur les conservait, l'utilisateur parlait au modèle via le serveur et l'invite elle-même était un détail d'implémentation que l'utilisateur ne pouvait pas voir. Techniquement vrai et complètement faux en pratique. Un utilisateur suffisamment curieux, utilisant des techniques d'extraction d'invite standard, pourrait pousser le modèle à révéler ses propres instructions, et une fois révélées, ces instructions seraient publiques. La confidentialité que j'avais imaginée n'était pas du tout de la confidentialité ; c'était un inconvénient mineur.

L'extraction spécifique n'était pas intelligente. L'utilisateur a demandé au modèle de résumer ses propres instructions, ce que la plupart des modèles font avec seulement une légère résistance, et a obtenu une paraphrase qui capture la substance. Pas les octets exacts de mon invite, mais l'intention, la structure, la logique opérationnelle. Assez pour que quelqu'un puisse reproduire ailleurs le comportement essentiel de l'assistant. Le fossé compétitif que j'avais supposé être dans l'invite était, rétrospectivement, un fossé à peu près aussi haut qu'une bordure.

La leçon que j'ai dû intégrer, inconfortablement, est que tout texte que vous placez dans le contexte d'un modèle est potentiellement détectable par les utilisateurs de ce modèle. Non pas "sera découvert par chaque utilisateur", mais "peut être découvert par des utilisateurs suffisamment déterminés". La bonne hypothèse est que l’incitation est l’information publique – visible éventuellement – ​​et qu’il faut concevoir autour de cette réalité plutôt que contre elle. Tout ce que vous ne pouvez pas vous permettre de divulguer ne devrait pas figurer dans une invite en premier lieu.

Les conséquences pratiques n’ont pas été aussi graves qu’elles auraient pu l’être, surtout par chance. L'invite contenait des instructions sur le comportement et le style, et non des données ou des informations d'identification confidentielles du client ou une logique métier qui auraient été préjudiciables entre de mauvaises mains. Si j'y avais stocké des informations sensibles (clés API, secrets commerciaux des clients, données personnelles), la fuite aurait été bien pire. Ce quasi-accident m'a appris à vérifier le contenu de chaque invite que j'ai écrite à partir de ce moment-là, en traitant chaque invite comme un texte que je serais à l'aise de voir publié, parce que je le pourrais.

La version de la leçon axée sur l'avantage concurrentiel est que si le fossé de votre produit est l'invite elle-même, votre produit n'a pas de fossé. Tout ce qui se trouve dans une invite est trivialement reproductible par toute personne suffisamment déterminée pour l'extraire. Les véritables fossés sont ailleurs : les données propriétaires, l'intégration du workflow, la relation continue, la confiance que le client a dans votre jugement. Essayer de défendre une invite comme les joyaux de la couronne, c'est défendre le mauvais atout. Déplacez la valeur vers un endroit que les utilisateurs ne peuvent pas extraire et traitez l'invite comme le texte public dont elle est fonctionnellement.

L'action de suivi que j'ai prise a consisté à examiner systématiquement chaque invite pour chaque compétence, à supprimer tout ce qui semblait servir de bouclier plutôt qu'à une conception, et à mettre à jour mon modèle mental pour supposer que chaque invite pouvait et pourrait devenir publique. Cet examen a pris une journée. Le changement de mentalité a pris plus de temps, car « les invites sont secrètes » est une hypothèse très naturelle qui doit être activement désappris. Ce n'est pas le cas ; traitez-les en conséquence.

Supposons que l'invite soit publique. Concevoir autour de cette hypothèse. Déplacez la valeur vers un fossé que les utilisateurs ne peuvent pas extraire, car l'invite n'en est pas une. La capture d'écran devient virale s'il le faut ; rien dans l'invite ne devrait pouvoir vous blesser si c'est le cas.

La démo qui a sauvé la transaction

À mi-chemin d'un argumentaire compétitif – trois fournisseurs, la décision du client arrivait vendredi, et mercredi matin, la forme de la conversation allait à mon encontre. Les concurrents avaient des diapositives soignées et de grandes feuilles de route. J'avais un PoC fonctionnel et une théorie très différente de ce que le client devrait acheter. Le moment où il s'est retourné n'était pas dans une glissade ; c'était dans une démo live que je n'avais pas prévu de donner au départ.

Ce qui a fait que la démo a fonctionné, c'est qu'elle n'était pas dramatique. Il ne s’agit pas d’une vitrine scénarisée où chaque contribution aurait été répétée ; une véritable utilisation en direct du système face à un problème qui tenait à cœur au client, réalisée devant lui, avec le risque qu'il ne fonctionne pas. J'ai tapé la vraie question du client dans l'assistant, nous avons regardé le flux arriver (l'interface de streaming du chapitre 14 gagnant sa place de la manière la plus littérale) et en quarante secondes environ, il y avait une réponse spécifique, utile et non générique sur leur écran. La démo a duré peut-être deux minutes. L'énergie de la pièce a sensiblement changé dès la fin de la première minute.

La raison pour laquelle cela a fonctionné était moins liée à la technologie qu’à ce que la démo avait prouvé. Les concurrents avaient montré des diapositives montrant ce que leurs systèmes feraient éventuellement ; J'avais montré une réponse spécifique à une vraie question spécifique, se déroulant dans la salle, sous les yeux du client. Le béton bat à chaque fois la théorie. Une démonstration où le risque d’échec est visible est plus crédible qu’une présentation soignée, car le client sait que rien n’est caché. Si ça marche, ça marche ; s'il se brise, cela aurait également été une information utile.

La leçon la plus profonde concerne ce à quoi ressemble réellement la « disposition à acheter » dans le processus de décision d’un client. Dans l'abstrait, ils comparent les listes de fonctionnalités et les informations d'identification des fournisseurs. Concrètement, ils tentent d'imaginer si le système va les aider, dans leur vrai travail, mardi prochain. Les diapositives et les feuilles de route les obligent à imaginer dur ; une démo en direct imagine pour eux. Le travail de la démo n'est pas de prouver la capacité de manière abstraite, mais de rendre le modèle mental d'utilisation du système suffisamment concret pour qu'il puisse prendre une décision.

Il existe un élément de gestion des risques qui mérite d’être mentionné. J'ai fait la démo parce que j'étais convaincu que le système fonctionnerait sur cette classe de questions, sur la base de la même classe de questions travaillée plusieurs fois lors des sessions précédentes. Je ne l'aurais pas fait si j'avais été incertain : une démo qui échoue dans un argumentaire compétitif est pire que pas de démo, car elle confirme le doute que les concurrents ont semé. La confiance dans la démonstration vient du fait d'avoir fait le travail ; quiconque est tenté d’essayer une démo en direct sans la fiabilité sous-jacente met en place sa propre crédibilité pour la démolition.

La dernière leçon est que la théorie de l’achat est importante. L'accord n'a pas été sauvé par la parité des fonctionnalités ou par l'éblouissement de la feuille de route ; il a été sauvé en changeant les termes de la comparaison de « évaluation du fournisseur » à « lequel de ces éléments m'aidera réellement ce mois-ci ». Une fois que la comparaison s'est portée sur des résultats concrets, la réponse spécifique et efficace de mon système à une question réelle était plus facile à comprendre que les descriptions bien produites des capacités éventuelles des concurrents. Réorienter la comparaison vers un terrain concret est souvent ce qui fait gagner des accords qui perdaient sur un terrain abstrait.

Des systèmes de démonstration qui font un vrai travail. Redirigez les comparaisons abstraites vers des résultats concrets. Effectuez le travail sous-jacent pour que la démo ait quelque chose à démontrer. C’est ce qui a sauvé cet accord, et le même modèle en a sauvé d’autres depuis – parce que « regardez ce qu’il fait réellement » bat presque toujours « voici ce qu’il finira par faire ».

Le client qui est parti

Tous les fiançailles ne se terminent pas bien. Un client a quitté l'entreprise au milieu de la deuxième année, et même s'il y avait des raisons superficielles (révision du budget, restructuration interne, nouvel acteur avec des priorités différentes), la lecture honnête était que la relation avait dérivé vers quelque chose qu'aucune des deux parties ne voulait vraiment, et le départ était une reconnaissance tardive. Les leçons d’un client qui part sont différentes de celles d’un client qui reste et méritent d’y consacrer un chapitre car les départs enseignent différemment.

La dynamique spécifique de cet engagement était que nous avions cessé d'avoir les critiques du chapitre 56 du type trentenaire au cours du cinquième mois. Nous avions tous les deux laissé l'élan faire avancer le travail sans vérifications périodiques, et au douzième mois, aucun de nous n'était vraiment sûr si l'engagement atteignait toujours son objectif initial ou autre chose. En l'absence de la structure délibérée consistant à s'arrêter et à regarder, nous avions dérivé vers un mode de maintenance qui nous semblait bien et qui n'était pas tout à fait ce que nous souhaitions. Ce départ était la fin naturelle d’une relation qui s’était déjà terminée en privé des mois plus tôt.

La leçon sur laquelle je reviens sans cesse est que les critiques pour lesquelles j'ai été si discipliné au cours du premier mois existent précisément pour éviter cela. Lorsqu’une relation a des enregistrements structurés continus, la dérive est nommée et corrigée ; quand ce n’est pas le cas, la dérive s’accumule silencieusement et le bilan final est bien plus important que n’importe quel examen simple ne l’aurait été. Le coût des évaluations manquées n'était pas payé à l'époque — tout allait bien —, il était payé au départ, lorsqu'il fallait concilier d'un coup une année de dérive.

La conversation de départ elle-même fut, curieusement, l’une des conversations les plus utiles de tout l’engagement. Les deux parties pouvaient être honnêtes comme elles ne l’avaient pas été depuis des mois, car l’issue était déjà décidée et il n’y avait aucun coût politique à révéler ce qui s’était réellement passé. Le client m'a expliqué précisément ce qui ne fonctionnait plus pour lui ; Je leur ai dit ce que j'avais remarqué mais que je n'avais pas évoqué. Aucun de nous n’a été surpris par ce que l’autre a dit. L’information était disponible depuis le début ; c’est le départ qui nous a libérés pour le reconnaître.

Le corollaire auquel je m'accroche depuis est d'avoir la conversation de type départ avant le départ, à une cadence régulière. Tous les examens ne doivent pas nécessairement être existentiels – la plupart ne sont que des contrôles – mais de temps en temps, les deux parties doivent pouvoir dire ce qui ne fonctionne pas, sans que le coût politique de cela ne soit perçu comme une menace pour l’engagement. Lorsque ces moments honnêtes peuvent survenir au sein de la relation, ils empêchent généralement le départ. Quand ils ne le peuvent pas, le départ est le seul endroit où ils peuvent se produire, et il est alors trop tard.

L’autre leçon concerne la façon de bien partir. Le client et moi nous sommes séparés avec un transfert écrit : ce que j'allais leur laisser, ce qui fonctionnerait encore, ce qui nécessiterait éventuellement une attention particulière. Ce n’est pas grave, ce n’est pas politiquement lourd, juste la courtoisie professionnelle de ne pas laisser de détails. Six mois plus tard, ce client m'a envoyé un appel de référence chaleureux concernant un nouveau prospect, ce qui est à peu près le meilleur résultat que vous puissiez espérer d'un départ. Bien partir est ce qui transforme un engagement perdu en un engagement futur.

Avoir les évaluations honnêtes dans les délais ; n'attendez pas le départ pour créer l'ouverture. Partez avec une remise écrite à la fin. Et prenez la conversation de départ comme des données : elle vous apprend des choses sur l'engagement que la version en cours ne pourrait pas avoir.

L'accord auquel j'ai dit non

La partie VII se termine sur les frais les plus élevés que j'ai refusés. L'engagement était substantiel, le client était réputé, le travail technique était dans ma zone. J'ai dit non parce que la forme de ce qu'ils demandaient était une forme que j'avais appris à reconnaître comme mauvaise pour moi, et honorer cette leçon comptait plus que les frais. Le chapitre explique comment dire non à une bonne affaire qui ne vous convient pas, car dire non est une compétence et je me suis trompé longtemps avant de réussir.

Le modèle spécifique de l'accord était le suivant : le client voulait l'exclusivité. Ils voulaient que je m'engage à ce que pendant un an, je n'accepte aucun client dans un espace adjacent, afin qu'ils soient les seuls bénéficiaires de mon travail dans leur secteur. Les frais qu'ils proposaient étaient calibrés pour que cette exclusivité en vaille la peine – véritablement plus que ce que je gagnerais normalement avec trois ou quatre engagements plus petits combinés. En apparence, c’était une bonne affaire. Sous la surface, c’était un piège dans lequel j’avais déjà été.

Le problème de l’exclusivité, de mon côté, c’est qu’elle concentre les risques. Si un client représente une grande partie de mes revenus et que ses besoins, ses priorités ou son budget changent (ce qui arrive régulièrement), j'ai perdu une grande partie de mes revenus en un seul événement. La diversification n'est pas un principe de portefeuille uniquement pertinent pour l'investissement ; cela s’applique avec autant de force à une pratique solo. Avoir six clients fournissant chacun un sixième de mes revenus est matériellement plus sûr que d'avoir un seul client qui fournit la totalité, même si le total est le même.

Le deuxième problème concerne les effets de l’exclusivité sur la pratique elle-même. Un engagement que je ne peux pas partager, dont je ne peux pas réutiliser les modèles, autour duquel je ne peux pas créer de clients de référence, est un engagement qui ne s'aggrave pas. La discipline de l'ensemble des compétences de la partie V dépend de la réutilisation des compétences au fil des missions ; la dynamique client de référence du chapitre 60 dépend de la capacité des clients à parler de moi publiquement. Les engagements exclusifs enferment tout ce que j'apprends chez un client dont je ne peux pas parler, ce qui ralentit la capitalisation dont je dépend pour ma croissance à long terme.

Le troisième problème, que j’ai mis le plus de temps à remarquer, est que l’exclusivité modifie l’équilibre des pouvoirs dans la relation. Lorsqu'un client sait que vous n'avez aucune autre entreprise dans son espace, il sait que vous ne pouvez pas marcher. Cette connaissance est subtile et se manifeste de mille manières : comment ils réagissent à vos factures, comment ils traitent les dérives de périmètre, à quel point ils s'attendent à ce que vous soyez flexible sur des choses qu'ils n'insisteraient pas s'ils savaient que vous aviez des alternatives. Les frais d’exclusivité constituaient exactement une compensation pour cette dynamique captive, et aucun frais ne compense suffisamment la position qu’il crée.

La conversation avec le client lorsque j'ai dit non était inconfortable – je n'avais jamais refusé une transaction de cette taille auparavant, et j'étais conscient qu'ils pourraient l'interpréter comme une posture pour des frais plus élevés. Honnêtement, j'ai dit qu'il ne s'agissait pas d'une position de négociation ; c'était une contrainte structurelle que j'avais appris à respecter. Ils ont été surpris, ils ont posé quelques questions et finalement ils m'ont engagé sur une base non exclusive pour un tarif inférieur – avec de bien meilleures conditions dans toutes les autres dimensions. Le refus s’est transformé en un meilleur engagement que ne l’aurait été l’offre exclusive.

La leçon généralise. Il existe certaines formes de transactions qui sont mauvaises pour un cabinet solo, quels que soient les honoraires qui y sont attachés – exclusivité, travail contre rémunération qui attribue vos modèles au client, engagements qui vous obligent à cacher vos autres clients – et apprendre à reconnaître ces formes est ce qui vous permet de dire non sans angoisser. Les frais spécifiques varient ; les formes ne le font pas. Une fois que vous connaissez les formes, la réponse est rapide, la conversation est courte et la pratique reste saine.

Connaître les formes qui nuisent à la pratique. Dites-leur non, quels que soient les frais. Ayez une conversation honnête. Parfois, la meilleure version de l’accord apparaît lorsque vous refusez la première version ; parfois ce n'est pas le cas, et c'est bien aussi. La santé professionnelle compte plus que n’importe quel frais.

Sur l'obsidienne

Je garde mes connaissances personnelles en Obsidienne. Je considère cela de manière vague - l'outil spécifique est moins important que le modèle de détention - mais j'ai essayé suffisamment d'alternatives pour avoir une idée de la raison pour laquelle les connaissances locales, basées sur des démarques et structurées par dossiers fonctionnent pour moi d'une manière que les alternatives hébergées dans le cloud et basées sur une base de données ne le font pas. Ce chapitre concerne le modèle, en utilisant l'obsidienne comme exemple concret.

La propriété sur laquelle je dépends est que les connaissances sont des fichiers texte sur mon disque. Pas dans le format propriétaire d'un service. Pas dans une base de données que j'aurais besoin d'exporter. Fichiers texte, dans des dossiers, dans Markdown, sur ma machine, synchronisés avec mes autres machines via le mécanisme de mon choix. Si Obsidian disparaissait demain, j'ouvrirais le dossier dans n'importe quel éditeur et continuerais. Si un service dans lequel mes notes vivaient disparaissait demain, j'aurais un problème de migration et éventuellement un problème de perte de données. La priorité locale n’est pas idéologique ; c'est une assurance.

La deuxième propriété est que le format survit mieux aux changements d’outillage que l’outillage. J'écris dans Markdown depuis suffisamment d'années pour que les notes d'il y a dix ans soient toujours lisibles dans l'éditeur actuel, l'éditeur actuel n'est pas celui que j'utilisais à l'époque, et aucune migration n'a jamais été nécessaire car Markdown n'a pas changé. Tout outil qui promet de retenir ma réflexion pendant des années doit posséder cette propriété ; tout ce qui lie ma réflexion à ses formats spécifiques évolutifs me demande de parier sur l'outil qui dure plus longtemps que mon besoin.

La troisième propriété, plus spécifique à la conception d'Obsidian, est que l'outil est un visualiseur de fichiers plutôt qu'un conteneur qui les possède. Obsidian ajoute une structure – liens, backlinks, vues graphiques, plugins – au-dessus des fichiers, mais les fichiers restent lisibles et utiles sans aucune de cette structure. La structure ajoutée est un bonus et non une dépendance porteuse. Si j'arrête d'utiliser Obsidian, je ne perds pas mes notes ; Je perds juste les possibilités qu'Obsidian ajoutait autour d'eux. Cette asymétrie – ajoute l’outil, ne tient pas en otage – est ce que je pense que les bons outils de connaissances devraient partager.

La généralisation que je veux tirer n’est pas que tout le monde devrait utiliser Obsidian. C'est que les propriétés que j'ai nommées - locales d'abord, basées sur du texte, outil en tant que visualiseur - sont les propriétés qui comptent pour tout ce que vous envisagez de conserver pendant des années. Lorsque vous évaluez un outil de connaissances, demandez-vous s'il possède ces propriétés, et non si sa liste de fonctionnalités correspond à la vôtre aujourd'hui. Les listes de fonctionnalités datent rapidement ; portabilité, texte brut, visionneuse sur propriétaire.

J'utilise beaucoup l'IA dans cette configuration, mais l'IA est un outil qui fonctionne sur les notes, pas un service qui les stocke. Mes compétences lisent et écrivent dans le répertoire des notes, produisent des artefacts qui cohabitent avec les notes et n'en deviennent jamais propriétaires. Si je voulais changer de fournisseur d’IA demain, mes notes resteraient intactes. La couche augmentée par l'IA repose sur le même substrat local que tout le reste, ce qui permet à l'ensemble du système d'être échangé.

Tenez les notes localement. Gardez-les dans le texte. Laissez les outils être des spectateurs et non des propriétaires. L'outil spécifique compte moins que les propriétés ; tout ce qui contient ces trois éléments est un pari raisonnable pour une connaissance à long terme, et tout ce qui ne les contient pas est un pari raisonnable pour éventuellement regretter.

Contre les plateformes LMS lourdes

Lorsqu'un client souhaite proposer une formation ou de la documentation dans le cadre d'un produit, la suggestion par défaut est souvent un « système de gestion de l'apprentissage » : une plate-forme lourde qui promet des cours structurés, un suivi des progrès, des quiz, des certificats, tous les attributs des logiciels éducatifs modernes. J'en suis venu à penser que pour la plupart de ces cas d'utilisation, un LMS lourd n'a tout simplement pas la bonne forme, et la bonne forme est plus proche d'un ensemble de pages bien organisées avec un index clair. Ce chapitre explique pourquoi.

L’observation principale est que les plates-formes LMS optimisent pour la mauvaise chose. Ils optimisent la capacité de l'administrateur à suivre les apprenants (pourcentages d'achèvement, scores aux quiz, mesures d'engagement) plutôt que la capacité de l'apprenant à réellement apprendre la matière. Les fonctionnalités qui rendent un LMS impressionnant à acheter sont celles qui rendent son utilisation moins bonne, car elles imposent une cérémonie en plus de ce qui devrait être une rencontre fluide avec le contenu.

La cérémonie spécifique que j'ai trouvée la plus dommageable est le gate – l'insistance du LMS pour qu'un utilisateur termine le module A avant d'ouvrir le module B. Dans le véritable apprentissage, les gens sautent. Ils viennent chercher la réponse spécifique dont ils ont besoin en ce moment. Ils revisitent une section qu’ils doivent revoir. Ils sautent des parties qu'ils connaissent déjà. Un LMS fermé rend tout cela impossible, en forçant un parcours linéaire à travers du matériel que la plupart des apprenants n'ont pas besoin de consommer de manière linéaire. La linéarité est la commodité de la plateforme et non l’avantage de l’apprenant.

L’alternative que je propose habituellement est ennuyeuse et fonctionne. Un ensemble structuré de pages, chacune autonome et lisible isolément, organisées par un index clair dans lequel l'apprenant peut naviguer librement. Une recherche qui fonctionne réellement. Liens entre les sections connexes. Pas de barres de progression, pas de séquences forcées, pas de certificats d'achèvement. Ce dont l'apprenant a besoin, c'est d'un contenu précis, bien rédigé, trouvable et lisible ; presque toutes les fonctionnalités du LMS au-delà de ce point sont des frictions déguisées en pédagogie.

Le contre-argument que j’entends le plus est que les clients veulent suivre l’engagement : combien d’apprenants ont parcouru le matériel, combien de temps ils y ont passé, quels ont été leurs scores. Équitable. Mais cet argument confond « nous voulons des données » avec « nous avons besoin d’une plate-forme lourde », et des mécanismes plus simples – analyses des pages vues, évaluations intégrées occasionnelles lorsque cela est réellement utile – couvrent l’essentiel de l’objectif du suivi sans imposer la cérémonie à chaque apprenant. Le suivi lourd vendu par les plates-formes LMS produit souvent des données sur lesquelles personne n'agit réellement, ce qui indique qu'il s'agit d'une cérémonie plutôt que d'un instrument.

Il y a un principe plus large qui mérite d'être souligné, à savoir que les outils « d'aspect professionnel » le sont souvent parce qu'ils ont ajouté une complexité qui répond aux attentes d'un utilisateur inconnu quant à ce à quoi ressemble un outil sérieux, et non parce que cette complexité répond aux besoins réels de chacun. Un contenu simple, bien organisé et respectueux de l'autonomie du lecteur a tendance à paraître moins impressionnant en démo et à être plus performant en utilisation quotidienne. L'impressionnante interface n'est pas corrélée à la qualité de l'apprentissage, et souvent anti-corrélée.

Expédiez un contenu structuré dans lequel l’apprenant peut naviguer librement. Suivez légèrement. Évitez le LMS, sauf si vous avez une véritable raison de formation accréditée pour en avoir besoin. Les apprenants accèdent plus rapidement au matériel ; les administrateurs obtiennent des tableaux de bord moins impressionnants et un engagement plus utile. Ce métier favorise les apprenants, à qui s’adresse théoriquement tout cela.

Décoration vs retenue

Le design a toujours tracé une ligne entre la décoration – des fioritures ajoutées pour plaire à l’œil – et la sobriété, la pratique consistant à supprimer ce qui ne mérite pas sa place. Les outils de conception générés par l’IA ont rendu la décoration bon marché d’une manière qui ne l’était pas historiquement, et mon point de vue est que la bonne réponse à une décoration bon marché est plus de retenue, pas plus de décoration. Parce que la retenue n’a jamais eu de valeur et que l’épanouissement était coûteux ; c'est que l'attention du lecteur est ce qui coûte cher, et que l'épanouissement la dépense.

Le modèle spécifique que j'ai observé au cours de la dernière année est que l'IA a rendu trivial la génération d'une grande variété visuelle - héros, icônes, illustrations, sous-titres avec des styles originaux - et de nombreux produits ont pris cela comme licence pour tout ajouter. Le résultat est une sorte de bruit de fond visuel qui n'existait pas auparavant, car le coût marginal de l'ajout d'une illustration représentait autrefois la journée d'un concepteur et maintenant, c'est une invite. Chaque illustration générée par l'IA sur une page qui n'en avait pas besoin attire l'attention du lecteur sur une décoration qui ne véhicule aucun signal.

Ma règle de travail est que chaque élément visuel d'une page doit mériter sa place en porteur d'un sens qui ne pourrait pas être transmis plus efficacement en prose. Un diagramme qui montre une structure que les mots ne peuvent pas capturer : mérite sa place. Une image de héros qui renforce l’état d’esprit dans lequel le lecteur doit se trouver : mérite sa place. Une illustration qui agrémente un titre de rubrique parce que la rubrique paraissait nue : ne mérite pas sa place. La section semblait vide car elle n'avait pas besoin de décoration, et en ajouter de toute façon oblige le lecteur à travailler plus dur pour trouver le contenu réel.

Le principe de retenue s'applique particulièrement à la typographie et à la couleur, où l'IA n'a pas encore rendu les choses moins chères mais où le même bon goût compte davantage. Une seule couleur d'accent, selon le chapitre 7, oblige le concepteur à décider de ce qui compte réellement. Une palette de polices limitée force la même discipline dans un registre différent. Chaque fois qu’un outil basé sur l’IA suggère « d’ajouter de la variété » à la typographie ou à la couleur, la bonne réponse est généralement de refuser, car la variété est la décoration et la discipline est le design.

Le point philosophique plus large concerne la différence entre « que puis-je faire » et « que dois-je faire ». Les outils bon marché élargissent considérablement la première question : vous pouvez générer de la variété visuelle, vous pouvez ajouter de l'épanouissement, vous pouvez tout décorer. Cela ne veut pas dire que vous devriez le faire. La réponse à la question incontournable est de savoir si l'ajout aide le lecteur ; la question peut être répondue par la question de savoir si l'outil le permet. Ce qui les rend confus, c'est la façon dont les produits se détériorent à mesure que les outils s'améliorent, car on demande aux outils de prendre des décisions qu'ils ne peuvent pas prendre.

Il existe un mode d'échec subtil où les praticiens défendent leur décoration en disant qu'elle « la rend plus vivante » ou « ajoute de la personnalité ». Parfois vrai, dans des contextes spécifiques. Souvent faux, dans le sens où « plus de variété visuelle » ajoute de la décoration sans ajouter de personnalité – la personnalité est une voix spécifique, pas un nombre spécifique d'illustrations. Lorsque l’argument en faveur d’un élément visuel est qu’il ajoute de l’ambiance plutôt que du sens, la bonne décision est généralement de le supprimer et de voir si la situation du lecteur est pire. Ce n’est généralement pas le cas.

Demandez si chaque élément mérite sa place. Coupez ce qui ne fonctionne pas. La retenue n’est pas une préférence esthétique ; c'est un respect pour l'attention du lecteur. La décoration bon marché exploite cette attention ; la retenue l'honore. Le design vieillit mieux et le lecteur parvient plus rapidement au sens.

Contre les invocations ad hoc

Je voudrais exprimer une opinion spécifique qui va à l’encontre de la façon dont travaillent de nombreux praticiens : l’invocation ponctuelle d’outils d’IA est une mauvaise habitude, et la discipline d’une seule porte d’entrée – comme l’explique le chapitre 3 – vaut la maladresse initiale de la construction. L'habitude de « simplement ouvrir Claude » ou « simplement d'ouvrir ChatGPT » lorsqu'une question se pose, sans aucune structure autour de ce qui se passe ensuite, est ce qui empêche les compétences de se transformer en quelque chose de plus grand.

Le schéma que je vois à plusieurs reprises est qu'un praticien a quinze ou vingt choses pour lesquelles il aimerait que l'IA l'aide, et chacune est traitée en ouvrant une nouvelle discussion et en décrivant la tâche à partir de zéro. Chaque séance est un démarrage à froid. Le résultat de chaque session ne figure que dans la transcription de cette session. Les petites victoires de chaque session ne donnent rien sur quoi la session suivante peut s'appuyer. C'est comme faire de la menuiserie sans atelier : chaque travail nécessite de configurer les outils à partir de zéro, sans gabarits, sans gabarits, sans pratique accumulée.

L’alternative consiste à faire de chaque tâche récurrente une compétence – une petite invocation nommée et structurée avec des entrées et des sorties définies – et à invoquer les compétences via une porte d’entrée cohérente. Le coût initial est réel : au lieu de simplement discuter, vous devez réfléchir à la nature réelle de la tâche, à quoi ressemblent les entrées, à quoi devrait être le résultat, où il doit être sauvegardé. Cette réflexion ressemble à un travail supplémentaire la première fois. Cela rapporte en un petit nombre de répétitions et se compose indéfiniment par la suite.

La raison pour laquelle je partage fermement cette opinion est que je l’ai fait dans l’autre sens pendant plus longtemps que j’aurais dû. J'ai discuté problème après problème, me sentant productif parce que chaque session produisait quelque chose, et à la fin d'un an, j'avais des milliers de transcriptions de discussion dispersées dans les historiques de service et, en réalité, aucune infrastructure complexe. Le résultat de chaque session s'était produit ; l'accumulation était nulle. C’est à ce moment-là que j’ai construit la porte d’entrée et la différence a été spectaculaire.

Le mode d'échec que je souhaite nommer est que l'invocation ad hoc est plus confortable que l'invocation structurée, et le confort dans ce contexte est un signe d'avertissement. Il suffit d’ouvrir une discussion et de commencer à taper sans friction. La friction liée à l'écriture d'une compétence pour une tâche que vous n'effectuerez qu'occasionnellement semble inutile. Le confort occulte le coût, à savoir que la troisième fois que vous effectuez une tâche similaire à partir de zéro, votre situation est déjà pire que si vous aviez investi vingt minutes dans une compétence la première fois. L’inconfort d’un petit investissement initial est le prix honnête de la capitalisation.

Il y a une nuance quant au moment où le ponctuel est acceptable, qui mérite d'être honorée. Pour des tâches véritablement ponctuelles qui ne se reproduiront jamais, les frais généraux liés à l’acquisition d’une compétence ne sont pas justifiés. Ouvrez une discussion, faites la chose, fermez-la. Mais l’erreur que commettent la plupart des praticiens est de qualifier de ponctuelles de nombreuses tâches qui sont en réalité récurrentes – une catégorie de travail qui se répétera, même si la prochaine instance exacte n’a pas été planifiée. La bonne question n’est pas « est-ce que je vais refaire exactement ça » mais « est-ce que je vais refaire quelque chose qui ressemble à ça », et la réponse est généralement oui.

Construisez la porte d’entrée. Structurez le travail récurrent en compétences. Réservez ad hoc pour les événements véritablement uniques. Cette habitude vous semblera un fardeau pendant quelques semaines et portera ses fruits pendant des années. C'est le métier; quiconque discute encore de son travail au cours de la deuxième année n'a pas encore vu la composition, et ne le fera pas tant qu'il n'aura pas construit l'atelier.

Ne polissez pas la maquette

Le chapitre 5 a établi le parti pris en faveur du transport maritime. Le chapitre 17 a construit le commutateur simulation/live. Le chapitre 53 plaidait en faveur du badge sur les données simulées. Ce chapitre est la version gustative du même argument : ne peaufinez pas les données fictives. Ne donnez pas l’impression que cela est réel. Ne passez pas quinze minutes à trouver « juste le bon » échantillon plausible. Expédiez la maquette la plus laide, la plus fausse de toute évidence, qui communique toujours la forme, et laissez la laideur être le point central.

L’instinct de polissage est fort et il faut y résister activement. Lorsque vous créez une page ou un composant, les données fictives entrent et les données fictives ne semblent pas tout à fait correctes, et la tentation est de passer quelques minutes à les faire ressembler à des données réelles plausibles. Des noms qui pourraient être de vraies personnes. Des montants qui pourraient être de véritables transactions. Des dates qui pourraient être des heures réelles. Quinze minutes ici, vingt minutes là, et maintenant la simulation est un faux magnifiquement conçu que tout le monde dans la revue traitera comme réel, ce qui est exactement l'échec que le badge du chapitre 53 essayait d'empêcher.

La conséquence de conception des simulations raffinées est pire que le risque de tromperie. Lorsque les données fictives semblent réelles, les conversations sur les produits portent sur la question de savoir si les chiffres spécifiques sont corrects (ce chiffre de revenus est-il plausible, le titre du poste de cet utilisateur est-il approprié) au lieu de savoir si la forme de la page est correcte, ce qui est le but de la simulation. Le polonais envoie les évaluateurs sur le mauvais axe d'évaluation. Les moqueries laides – délibérément, évidemment laides – obligent les critiques à examiner la structure, car la surface n'invite pas à un examen minutieux du contenu.

Ma pratique de travail consiste à utiliser de manière agressive de fausses données simulées. Le nom de chaque utilisateur est « Utilisateur test ». Chaque montant est un nombre rond. Chaque date est un espace réservé. Chaque image est un rectangle coloré. La page communique toujours sa forme – les colonnes, la mise en page, le flux – mais rien dans les données ne prétend être réel. Les examinateurs ne peuvent pas se tromper sur ce point, car il ne peut pas s’agir de données, qui ne sont visiblement pas des données.

Il y a un domaine où cela devient controversé : les démonstrations commerciales. Les responsables du produit veulent parfois des maquettes raffinées pour les démos, sur la base de la théorie selon laquelle des données réelles aident l'acheteur à imaginer utiliser le produit. Je ne suis pas d'accord; une simulation qui prétend être réelle est une simulation qui finira par être mémorisée à tort comme une caractéristique spécifique que le produit ne possède pas, en fait. Le dividende démo est à court terme ; le problème des attentes en matière de fonctionnalités est à long terme. Ma préférence dans les démos est d'utiliser de petites quantités de données véritablement réelles ou d'afficher des données clairement simulées avec le badge, et de faire de la forme du produit une histoire plutôt que la plausibilité d'un exemple spécifique.

La leçon générale est que le faux qui semble réel est une catégorie de piège, appliquée au sens large. Les faux tableaux de bord qui semblent réels sont mal interprétés. De faux rapports qui semblent réels sont transmis. De fausses voix qui semblent réelles sont citées. Dans tous les cas, la bonne réponse est de rendre le faux manifestement faux – le but n’est pas de tromper, le but est de communiquer une forme suffisamment tôt pour que les commentaires réorientent le travail. Tromper va à l’encontre du but recherché ; une falsification évidente le sert.

Des moqueries laides. Faux noms, chiffres ronds, rectangles colorés. Enregistrez le vernis pour les données réelles, lorsqu'elles arrivent. Le travail du simulacre est de provoquer une réaction à la forme ; tout ce qui provoque une réaction à la substance ne fait pas le bon travail.

Les cadres comme goût

Chaque praticien accumule un ensemble de cadres – modèles mentaux, modèles de code, heuristiques de décision – qu’il utilise par défaut. Ces cadres ne sont pas neutres ; ce sont des expressions de goût, et les appeler goût plutôt que vérité est ce qui maintient une pratique honnête. Les frameworks que j'utilise sont ceux que j'ai trouvés les plus utiles ; cela ne les rend pas universellement corrects, et cela n'en fait surtout pas un modèle que quiconque devrait adopter sans les traduire.

Le mode d’échec que je souhaite nommer au début consiste à traiter vos propres frameworks comme la manière objectivement correcte de travailler. Lorsque vous utilisez une approche depuis des années et qu'elle vous a bien servi, vous commencez à avoir l'impression que les choses sont telles qu'elles sont, plutôt que telles que vous les avez organisées. Il s’agit d’une catégorie de dérive cognitive qui afflige tout praticien au-delà d’une certaine ancienneté, et l’antidote est de continuer à dire « voici ce qui fonctionne pour moi » plutôt que « voici comment cela devrait être fait ».

L'exemple concret que j'utilise avec moi-même est la décomposition en piliers du chapitre 4 — Orchestrer, Encadrer, Produire, Créer, Agir. Ce sont cinq piliers car ce sont les cinq catégories que j'ai vues lorsque j'ai décomposé mon travail. Le travail de quelqu'un d'autre peut se décomposer en six ou quatre piliers, ou en un ensemble complètement différent de catégories qui ne correspondent pas bien au mien. Le principe MECE est juste – la suite de chaque praticien doit être exclusive et exhaustive – mais les piliers spécifiques sont le goût, pas la loi.

La raison pour laquelle cela est important en pratique est que le transfert d’un cadre d’un praticien à un autre nécessite généralement une traduction. Un collègue junior adoptant mes piliers en bloc hériterait des étiquettes sans le raisonnement sous-jacent, et les étiquettes conviendraient moins bien à leur travail qu’une nouvelle décomposition. Ce que j'ai appris à transmettre, c'est le méta-cadre — « décomposez votre travail en piliers MECE, nommez-les à partir de votre propre expérience » — plutôt que mes réponses spécifiques, qui dépendent de mon travail spécifique.

La version plus large de cet argument est qu’Internet regorge d’opinions confiantes sur « la bonne façon » de faire de l’ingénierie de l’IA, et la plupart de ces opinions sont le goût de quelqu’un transformé en règle. Prenez-en le goût, traduisez-le par rapport à votre propre réalité, gardez ce qui vous convient, jetez ce qui ne vous convient pas. Les praticiens dont vous empruntez les cadres empruntent généralement eux-mêmes à quelqu'un d'autre, et l'autorité du cadre vient du fait qu'il a été testé quelque part, et non de son application universelle.

J'ai observé un modèle spécifique d'échec de l'adoption d'un framework : quelqu'un lit un livre comme celui-ci, ou un article de blog bien argumenté, et applique ses recommandations spécifiques en gros : mêmes piliers, mêmes outils, même flux de travail. Le résultat est une version de la pratique de l'auteur greffée sur son œuvre, et elle s'intègre mal, car l'œuvre sous-jacente est différente. Six mois plus tard, ils abandonnent le cadre et concluent que l'auteur avait tort, alors que le cadre était mal traduit. Le problème n'était pas le cadre ; le problème était que les cadres sont du goût et que le goût ne se transfère pas directement.

Tenez vos cadres avec conviction et humilité à la fois. Énoncez-les clairement. Traduisez-les impitoyablement lorsque vous appliquez ceux de quelqu'un d'autre. Mettez à jour le vôtre lorsque votre travail change. Les cadres sont la manière dont vous organisez la pensée, pas sa vérité. Et les cadres spécifiques de ce livre – chacun d’entre eux – sont mes réponses de travail, proposées comme une forme de bonne pratique, et non la seule.

Le problème du portable

Les notebooks Jupyter et leurs proches (cellules que vous exécutez dans l'ordre, sorties entrelacées de code, exploratoires et finales dans le même fichier) sont devenus le moyen par défaut de partager une grande partie du travail d'IA. Je les utilise. Je souhaite également citer une catégorie de problèmes qu'ils créent, car l'enthousiasme pour les ordinateurs portables a discrètement remplacé des habitudes qui, à mon avis, comptent davantage, et le commerce n'est pas neutre.

Le problème spécifique est que les ordinateurs portables encouragent le développement cellule par cellule, et le développement cellule par cellule produit du code qui ne fonctionne que dans l'ordre spécifique dans lequel le développeur a exécuté les cellules. Pas l'ordre dans lequel les cellules apparaissent dans le bloc-notes - l'ordre dans lequel le développeur a cliqué, qui est souvent assez différent, surtout lorsqu'il est revenu pour réparer quelque chose et n'a jamais réexécuté les cellules en aval. Un bloc-notes qui "fonctionne" dans le sens où toutes les cellules se sont terminées avec succès pourrait ne pas fonctionner du tout s'il était exécuté de haut en bas sur un nouveau noyau, et le développeur pourrait ne pas le savoir.

La dépendance entre les cellules est invisible dans le notebook lui-même. Aucun compilateur ne vous indique que la cellule douze dépend d'une variable qui a été redéfinie pour la dernière fois dans la cellule huit mais modifiée dans la cellule vingt-trois. Vous pouvez exécuter la cellule douze à tout moment et elle utilisera la valeur que la variable contient actuellement dans la mémoire du noyau, qui est fonction de votre historique de clics et non de l'ordre textuel du bloc-notes. Il s'agit d'une catégorie d'état caché que les scripts classiques n'ont pas, et elle produit une catégorie de bogues — « a fonctionné dans mon noyau, pas dans le vôtre » — qui est spécifique aux notebooks.

Le mode d'échec que j'ai observé à plusieurs reprises est un cahier partagé comme preuve d'une méthode de travail qui échoue ensuite lorsqu'il est reproduit. Le destinataire exécute les cellules dans l'ordre, rencontre une erreur, la renvoie à l'auteur, qui est véritablement surpris car "ça a fonctionné pour moi". Les deux disent la vérité. Le notebook a fonctionné dans un historique d'exécution spécifique et ne fonctionne pas dans le cas général. Ce n'est pas vraiment le problème du destinataire ; c'est un artefact de l'outil.

Ce que je fais à ce sujet, c'est de traiter les cahiers comme des espaces de travail pour l'exploration et de distiller les découvertes de travail dans des scripts ou des modules ordinaires avant de les partager avec qui que ce soit. Le cahier est l'endroit où je découvre ce qui fonctionne ; le script est ce que je partage, car l'ordre d'exécution d'un script est sans ambiguïté et ses hypothèses d'état sont explicites. Cela coûte une étape – la distillation – que les purs passionnés d’ordinateurs portables ne franchissent pas, et je pense que c’est exactement là que la reproductibilité gagne sa place.

L'argument de Steelman en faveur des cahiers que je prends au sérieux est qu'ils sont excellents pour l'enseignement et pour la présentation exploratoire, car l'entrelacement de la prose, du code et des résultats est véritablement utile lorsqu'il s'agit de guider le lecteur dans un processus de raisonnement. Dans ces contextes, les cahiers sont le bon outil. Ce pour quoi ils ne sont pas le bon outil, c'est le travail de production que d'autres personnes devront exécuter, étendre ou faire confiance. Artefact pédagogique, oui ; artefact de production, non ; et c'est en confondant les deux que réside le problème des ordinateurs portables.

Utilisez des cahiers pour ce pour quoi ils sont bons. Distiller les scripts pour ce qu'ils ne sont pas. Ne partagez pas les cahiers d’exploration comme s’il s’agissait de produits de travail reproductibles ; ce n'est pas le cas, quel que soit le soin avec lequel vous avez exécuté les cellules. L’habitude de la distillation est ce qui sépare le travail d’IA reproductible du travail d’IA irréproductible magnifiquement présenté.

Le label « AI-Native »

Au cours de la dernière année, l'expression « IA-native » a commencé à s'attacher à chaque produit, flux de travail et conseil incluant un modèle de langage quelque part. J'ai moi-même utilisé cette expression dans ce livre, et je veux passer un chapitre à m'en méfier, car l'étiquette s'est suffisamment éloignée de sa signification utile pour qu'il s'agisse principalement de bruit maintenant, et le bruit se faisant passer pour un signal mérite d'être examiné.

La signification utile initiale du label était une distinction : les produits construits en supposant qu'un modèle d'IA était un composant de premier ordre de l'architecture, par rapport aux produits qui avaient boulonné un modèle sur une forme existante. L’IA native signifiait que le modèle façonnait le produit ; l’alternative – appelez-la augmentée par l’IA – signifiait que le produit façonnait la façon dont le modèle était utilisé. La distinction était réelle et méritait d’être mentionnée, car les deux catégories produisaient souvent des expériences très différentes, même lorsque leurs listes de fonctionnalités semblaient similaires.

Ce que l'étiquette est devenue, dans l'usage de l'industrie, est une affirmation marketing auto-appliquée par quiconque veut signaler qu'il est moderne. Chaque startup se présente comme étant native de l’IA. Chaque cabinet de conseil revendique une pratique native de l’IA. Chaque feuille de route de produit parle de fonctionnalités natives de l’IA. Lorsqu’une étiquette s’applique à tout le monde, elle ne distingue plus rien et la réponse honnête est soit d’abandonner l’étiquette, soit d’être précis sur ce que vous entendez lorsque vous l’utilisez.

Mon remplacement, lorsque je veux parler de la distinction sous-jacente, consiste à décrire ce que le produit fait réellement avec le modèle. Le modèle prend-il les décisions fondamentales ou aide-t-il les humains à les prendre ? Le modèle se situe-t-il dans le chemin critique du succès de l'utilisateur, ou dans un rôle secondaire d'assistance ? La forme du produit change-t-elle fondamentalement sans le modèle, ou le modèle est-il une fonctionnalité autour de laquelle le produit pourrait fonctionner ? Ces questions produisent des réponses concrètes ; "Est-ce que c'est une IA native" ne le fait plus.

Le soupçon corollaire que je souhaite exprimer est que « IA-native » en tant qu'auto-descripteur est un léger signal négatif à propos du locuteur. Pas toujours – beaucoup de personnes réfléchies l’utilisent dans son sens originel – mais souvent. Les praticiens qui s'appuient sur l'étiquette substituent souvent une allégation marketing à un argument de conception, et les détails dont ils auraient besoin pour faire valoir l'argument de conception ne sont pas là. Demandez à un produit soi-disant natif de l’IA ce qui le rend natif, et les réponses doivent être spécifiques et structurelles ; s'ils sont vagues et basés sur des vibrations, le label signale plus qu'il ne gagne.

Le schéma plus large que cela illustre mérite d’être cité : l’industrie technologique génère de nombreuses étiquettes, la plupart d’entre elles tentent de se différencier au début et sont banalisées par une utilisation excessive, et le praticien honnête doit continuer à mettre à jour son vocabulaire à mesure que les étiquettes perdent leur sens. "Cloud-native" a traversé cet arc il y a dix ans. "À l'échelle du Web" avant cela. "AI-native" est l'instance actuelle, et elle sera remplacée par autre chose, et les mêmes soupçons s'appliqueront au remplacement. Les étiquettes sont des marqueurs de la mode actuelle, et non des preuves de la substance actuelle.

Méfiez-vous de l'étiquette. Demandez les détails derrière cela. Lorsque vous parlez, décrivez ce que fait réellement le produit ou la pratique plutôt que de recourir à des raccourcis marketing. La substance vieillit mieux que les étiquettes ; les étiquettes expirent lorsqu’elles sont surutilisées, et l’expiration est en bonne voie.

Sur les certifications

L'industrie de l'IA a commencé à produire des certifications, c'est-à-dire des cours qui promettent de vous accréditer en tant que praticien compétent, avec des examens, des badges et des bénédictions spécifiques des fournisseurs. J'ai des opinions sur les certifications en général et sur les certifications IA en particulier, et ce chapitre est ma tentative de les exprimer honnêtement, car ce ne sont pas des opinions populaires et prétendre qu'elles le sont serait malhonnête.

La conception populaire des certifications est qu'elles constituent une preuve de compétence – un moyen pour un praticien de démontrer à des clients ou des employeurs potentiels qu'il maîtrise un ensemble de connaissances, ratifiées par une autorité indépendante. Dans les domaines où l’ensemble des connaissances est stable et la pratique est réglementée (médecine, aviation, droit), les certifications remplissent précisément cette fonction et elles sont importantes. Dans les domaines logiciels en évolution rapide, ce n'est généralement pas le cas, car l'ensemble des connaissances évolue plus rapidement que les certifications ne peuvent être mises à jour, et la devise du certificat expire au moment où il est obtenu.

Dans le domaine de l’IA en particulier, ce problème est aigu. Une certification développée l'année dernière vous examine sur un ensemble de connaissances déjà partiellement obsolètes : les comportements des modèles ont changé, les meilleures pratiques ont évolué, des catégories entières d'outils sont apparues ou ont été obsolètes. Le certificat indique que vous saviez ce qu'un groupe d'experts considérait comme important à une date limite ; cela ne dit pas que vous savez ce qui est important maintenant, et « maintenant » évolue assez rapidement pour que l'écart compte.

Le problème le plus profond que j’ai avec les certifications en IA est qu’elles encouragent le remplacement des diplômes par la pratique. Une personne possédant la certification peut la présenter comme une preuve d'expertise ; quelqu'un qui n'en a pas doit faire valoir ses arguments sur la base de ce qu'il a réellement fait. La certification est plus facile à afficher que le portfolio, elle devient donc le signal par défaut – et désormais le signal est un diplôme plutôt qu'un travail, qui sélectionne les personnes qui acquièrent des diplômes plutôt que celles qui travaillent. C’est exactement l’inverse pour un domaine où faire le travail est ce qui enseigne et où le travail avance plus rapidement que ne le peuvent les diplômes.

Le steelman que je reconnais est que les certifications fournissent un plancher. Dans un marché où n’importe qui peut se qualifier de consultant en IA, une certification indique au moins que le titulaire s’en soucie suffisamment pour étudier quelque chose. C'est un vrai signal, plus faible qu'un portefeuille mais plus fort que rien. Pour le recrutement à grande échelle, les certifications peuvent constituer un filtre raisonnable – non pas une preuve de compétence, mais un indicateur de « a pris cela suffisamment au sérieux pour suivre un cours formel ». J'embaucherais un candidat certifié plutôt qu'un candidat non accrédité, toutes choses égales par ailleurs, mais j'embaucherais un candidat avec des artefacts fonctionnels visibles sur les deux.

Mon conseil aux praticiens est de donner la priorité au portfolio de travail plutôt qu’au titre. Expédiez les choses, publiez-les, laissez-les examiner. Un système fonctionnel unique qui résout un problème réel communique davantage sur la compétence que n'importe quelle certification, car vous pouvez inspecter l'artefact plutôt que de faire confiance au certificateur. Si vous possédez les deux – un titre et un portfolio – le titre ajoute un petit montant à la marge. Si vous devez choisir, choisissez le portefeuille et laissez le certificat être un atout que vous récupérerez plus tard.

Les certifications ne sont pas nuisibles. Ils représentent tout simplement moins de signaux qu'ils ne le prétendent, surtout dans un domaine qui évolue aussi rapidement. L’alternative – construire la chose, la montrer – vieillit mieux et communique davantage. Prenez le certificat si vous le souhaitez, mais n'arrêtez pas de construire pendant que vous étudiez.

Ce que les influenceurs se trompent

La Partie VIII se termine sur une opinion spécifique et malvenue : une grande partie de ce qui circule sous forme de conseils en matière d'ingénierie de l'IA provenant d'influenceurs des médias sociaux est erroné d'une manière qui induit les nouveaux praticiens en erreur, et identifier les raisons spécifiques pour lesquelles cela est faux mérite un chapitre, car le modèle d'erreur est lui-même informatif. Ce n’est pas personnel et ce n’est pas une critique envers tous ceux qui ont un public ; c'est une taxonomie des erreurs spécifiques que je continue de voir.

La première erreur consiste à confondre les démos et les produits. Une démo fonctionne une fois, dans des conditions contrôlées, pour un exemple spécifique. Un produit fonctionne de manière fiable, dans des conditions incontrôlées, pour un large éventail d'exemples que le fabricant n'avait pas prévu. Les influenceurs qui présentent des démos impressionnantes comme preuve de ce qui est possible en production ne mentent généralement pas : ils confondent deux catégories de choses dont le public ne sait pas qu'elles sont différentes. La démo a vraiment fonctionné. La version produit pourrait ne jamais fonctionner du tout.

La deuxième erreur est de sous-estimer la charge opérationnelle. Les systèmes intégrés à l'IA nécessitent plus de travail à exploiter que ne le laisse entendre la démo, car le modèle est une dépendance en direct avec des régressions, des limites de taux et des bizarreries. Le contenu qui se concentre uniquement sur le côté « regardez ce que j'ai construit en un après-midi » du travail d'IA est véridique sur cet après-midi et silencieux sur les six mois de maintenance suivants. Les nouveaux pratiquants voient l'après-midi et ne savent pas que les six mois existent ; ils sont ensuite surpris lorsque leurs propres systèmes nécessitent les six mois qu'ils n'avaient jamais budgétisés.

La troisième erreur est la surattribution à des outils spécifiques. Un modèle qui fonctionne avec l'outil X est attribué au fait que l'outil X est magique, alors que souvent, le modèle fonctionnerait aussi bien avec l'outil Y ou l'outil Z. Les influenceurs dont les revenus dépendent des affiliations avec des outils spécifiques ont une réelle incitation à sur-attribuer des modèles réussis à ces outils, et le public ne peut pas toujours faire la différence entre « cet outil a activé le modèle » et « ce modèle a été montré à l'aide de cet outil ». La bonne question est toujours de savoir si le modèle est portable ; c’est généralement le cas et l’outil est fongible.

La quatrième erreur est le modèle « voici comment construire [un grand système] en [petit temps] ». Ces didacticiels laissent presque toujours de côté les parties qui nécessitent du temps réel (conception de schéma, gestion des cas extrêmes, déploiement, surveillance, sécurité) et ne proposent que le chemin heureux de base comme s'il s'agissait de l'ensemble du système. Les nouveaux pratiquants essaient de reproduire le didacticiel, de trouver les œuvres du chemin heureux, puis de se lancer dans le travail omis et de conclure que le didacticiel a menti. Ce n’est pas exactement le cas ; ce n'était tout simplement pas une version de production complète, et cela considérait une version partielle comme complète.

La cinquième erreur consiste à présenter les techniques de pointe comme immédiatement pratiques. Certaines recherches récentes sont véritablement applicables au travail de production ; certains sont fascinants sur le plan académique et il faudra des années avant d'être sûrs ou pratiques dans des systèmes réels. Les influenceurs qui ne font pas de distinction entre les deux produisent un contenu passionnant à lire et trompeur à utiliser. Les nouveaux praticiens essaient d'appliquer une technique qui n'est pas prête et concluent qu'ils doivent la faire mal, alors que la réponse honnête est que la technique n'était pas prête au départ.

Aucune de ces erreurs n'est malveillante. La plupart sont le résultat honnête de la mise en correspondance de ce qui suscite l'engagement (démonstrations impressionnantes, petits investissements en temps, outils spécifiques, techniques de pointe) avec ce qui éclaire réellement la pratique. Les deux se chevauchent partiellement et les parties où elles divergent sont celles où résident les erreurs. Les praticiens qui apprennent de ce contenu doivent connaître l’existence de la divergence et se calibrer en conséquence.

Considérez le contenu de l’IA des réseaux sociaux comme une source d’idées à étudier, et non comme des conclusions sur lesquelles agir. Vérifiez par rapport à votre propre expérience ou à celle de quelqu'un dont les incitations ne sont pas axées sur le public. La valeur est réelle une fois calibrée ; le mal est réel alors qu'il ne l'est pas. Consommez les yeux ouverts et maintenez la silhouette de chaque influenceur – y compris la mienne – avec le même scepticisme que ce chapitre défend.

Vérification des informations sur les produits

Le type d'échec le plus évitable que j'ai observé - dans mon propre travail et dans celui des autres - est la publication de contenu contenant des erreurs factuelles sur le produit qu'il décrit. Une déclaration de fonctionnalité qui ne correspond pas à ce que fait réellement le produit. Un chiffre qui est décalé d'un ordre de grandeur. Une capture d'écran qui montre un état que le produit actuel ne peut pas atteindre. Ce ne sont pas des erreurs sophistiquées ; ils sont courants et ils sapent la confiance d'une manière qui prend beaucoup de temps à regagner.

La raison spécifique de cet échec dans les flux de travail augmentés par l'IA est que le modèle peut produire des phrases sûres et plausibles sur le comportement du produit qui sont tout simplement fausses - parce que le modèle n'était pas là lorsque le produit a été construit, n'a pas accès à l'état actuel du code et déduit le comportement de la forme générale de produits similaires. Toute phrase décrivant une fonctionnalité spécifique est susceptible d'être fausse, et plus la revendication est spécifique, plus vous devez être prudent dans sa vérification avant sa livraison.

Ma discipline de travail est que chaque affirmation factuelle sur le produit dans tout contenu publié soit vérifiée par rapport au produit réel avant la publication. Pas "Je me souviens que cela fonctionnait comme ça" - vérifié activement en examinant l'état actuel. Cela semble évident. C'est la pièce que je vois sauter le plus souvent, surtout sous la pression du temps, et c'est la pièce dont l'omission produit le plus d'embarras évitable.

Le mécanisme que j'utilise est une petite liste de contrôle qui s'exécute après la rédaction de tout contenu. Lisez chaque phrase qui fait une affirmation factuelle. Pour chacun d'entre eux, demandez : "est-ce vérifiable et l'ai-je vérifié ?" Vérifiable signifie que cela correspond à quelque chose que je pourrais confirmer : une page du produit, une valeur de configuration, une sortie spécifique. Vérifié signifie que j'ai effectivement effectué la confirmation, et non que j'ai l'intention de le faire. Toute phrase invérifiable est signalée pour vérification ou suppression ; toute phrase non vérifiée est vérifiée avant d'être autorisée à être expédiée.

La liste de contrôle est ennuyeuse, et c’est son caractère ennuyeux qui la rend fiable. Il s'agit d'un passage de cinq minutes à la fin de l'écriture qui détecte la plupart des erreurs qui autrement embarrasseraient le navire. Le sauter sous la pression du temps est une fausse économie : les cinq minutes économisées avant la publication se transforment ensuite en heures de réparation de la confiance, et les erreurs spécifiques qui sont expédiées sont souvent de celles qui donnent l'impression que l'ensemble du document n'est pas fiable plutôt que simplement erroné sur un point.

Il existe une discipline complémentaire qui s'applique au sein du processus de rédaction lui-même : lorsque le modèle produit du contenu sur le produit, incitez-le à faire la distinction entre les affirmations sur lesquelles il a confiance et les affirmations qu'il déduit. Non pas parce que le modèle connaîtra toujours la différence – ce n’est souvent pas le cas – mais parce que forcer le modèle à se couvrir produit un texte plus facile à vérifier. Une phrase qui dit « cette fonctionnalité fait X (vérifier) ​​» est plus facile à vérifier que la même phrase prononcée avec confiance, et les jetons « (vérifier) ​​» de fin sont une assurance bon marché pendant la rédaction.

Vérifiez chaque affirmation factuelle. Utilisez une liste de contrôle ennuyeuse. Forcez le modèle à se protéger contre l'incertitude. Effectuez le contrôle même sous la pression du temps ; surtout alors. L’erreur publiée que vous évitez vaut bien plus que les cinq minutes nécessaires pour la détecter.

Artefacts Esbuild-Clean

Ce chapitre concerne une barre de qualité spécifique pour les artefacts produits par un système, en utilisant le mot « esbuild-clean » comme raccourci. Le mot vient des outils JavaScript - esbuild est un bundler qui refusera de terminer une construction si quelque chose est mal formé - et j'en suis venu à l'utiliser plus largement pour décrire des artefacts qui passent sans problème le contrôle structurel raisonnable le plus strict. Un artefact qui génère des avertissements, nécessite des corrections manuelles ou présente des problèmes logiciels n'est pas esbuild-clean ; la barre est qu'elle survit à un outillage strict sans aucun réglage manuel.

La raison pour laquelle cela est important est que les artefacts générés par l’IA sont souvent livrés avec des problèmes structurels subtils qui sont individuellement petits – une importation inutilisée, un type incompatible, un point-virgule manquant, un caractère d’espacement parasite – dont aucun humain ne se soucierait individuellement mais qui s’accumulent dans un arrière-plan de mauvaise qualité. Chacun d’eux est facile à laisser tranquille. Collectivement, ils signalent un artefact qui a été produit sans soin, et les outils en aval qui s'attendent à des artefacts propres commencent à s'étouffer avec eux.

La discipline consiste à traiter « un outillage strict sans avertissement » comme la définition de complet. Si le linter se plaint, ce n'est pas fait. Si le vérificateur de type avertit, ce n'est pas fait. Si le formateur voulait le réécrire, ce n'est pas fait. Il s'agit d'une norme plus stricte que celle appliquée par la plupart des bases de code, et c'est la norme qui maintient l'artefact durable - car chaque avertissement toléré dans le code aujourd'hui est un avertissement qui s'accumulera avec le prochain avertissement et le suivant, jusqu'à ce que le signal de l'outil soit noyé dans le bruit.

L'élément spécifique à l'IA est que lorsqu'un modèle produit du code ou du contenu, il produira volontiers une sortie techniquement fonctionnelle mais bâclée : importations supplémentaires, conditions redondantes, style incohérent. Si elle n’est pas corrigée, cette négligence s’accumule dans la base de code au fil du temps. Ma pratique de travail consiste à exécuter chaque artefact produit par le modèle via l'outillage strict avant de l'accepter, et à corriger ou rejeter tout ce qui génère des avertissements. Il peut être demandé au modèle de corriger sa propre sortie ; souvent, cela peut être fait à moindre coût. Ce qu’il ne peut pas faire, c’est savoir que le résultat est inacceptable sans qu’on le lui dise.

Le mécanisme que j'utilise est que le résultat de chaque compétence passe par une petite étape de « vérification propre » avant d'être écrit dans le magasin d'artefacts. Si le contrôle réussit, l'artefact est stocké ; en cas d'échec, le résultat de la vérification est renvoyé au modèle avec une demande de correction, jusqu'à une certaine limite de tentatives. Au-delà de cette limite, l'exécution échoue proprement et je l'examine. Cela signifie que les artefacts qui arrivent dans le magasin sont, par construction, propres à la construction ; ceux qui n’y sont pas parvenus n’ont jamais atterri.

Il y a un principe plus large sous-jacent, à savoir que les normes de qualité doivent être appliquées autant que possible par l'outillage, car la discipline humaine s'érode sous la pression du temps, ce qui n'est pas le cas de l'outillage. Une équipe qui s'appuie sur « nous vérifions toujours X avant l'expédition » ne vérifiera parfois pas X lorsque les choses sont occupées ; un système de construction qui ne se terminera pas lorsque X n'est pas propre vérifiera toujours X, pour toujours. Déplacez la norme de la discipline vers l’application, et la norme survit.

Outillage strict, zéro avertissement toléré. Renvoyez les échecs au modèle pour les corriger. Imposer la qualité par la construction et non par l'espoir. Esbuild-clean n'est pas un terme uniquement JavaScript ; c'est une barre de qualité qui mérite d'être adoptée dans tout, et qui mérite d'être défendue contre le « eh bien, ça marche, alors… » qui arrive toujours quand quelqu'un ne veut pas réparer les petites choses.

Les artefacts structurés bouclent la boucle

Chaque chose significative produite par un système doit être un artefact structuré – un fichier, un enregistrement, un document avec une forme connue – car les artefacts structurés sont les seuls qui ferment la boucle de vérification. La sortie non structurée peut être examinée ; les résultats structurés peuvent être vérifiés, comparés, agrégés et audités. La différence n’est pas cosmétique ; il s'agit de savoir si la vérification est possible.

Le modèle que je souhaite nommer est que lorsque les résultats d’un système sont structurés, la vérification en aval devient réalisable. Un rapport qui suit un schéma connu peut être vérifié champ par champ par rapport aux attentes. Un fichier généré qui correspond à un format connu peut être comparé aux versions précédentes. Une trace structurée peut être interrogée pour les anomalies. Chacun de ces éléments dépend du fait que la sortie ait une forme sur laquelle vous pouvez pointer ; les sorties non structurées (texte libre, fichiers blob, blobs de données non étiquetés) ne peuvent pas être vérifiées systématiquement, mais seulement observées.

La boucle de vérification spécifique qui m'intéresse est la suivante : le système produit un artefact, une vérification est effectuée sur l'artefact, et la vérification confirme que l'artefact répond à ses critères ou nomme ce qui ne va pas. Cette boucle doit s’exécuter automatiquement, sans intervention humaine, pour que la production d’artefacts soit fiable à grande échelle. Et cette boucle n'est possible que si l'artefact est suffisamment structuré pour que les contrôles automatisés aient quelque chose à vérifier.

La tentation avec les résultats générés par l’IA est de les accepter comme de la prose, car la prose est ce que le modèle produit naturellement. Chaque acceptation de prose là où une sortie structurée était possible est un petit échec de la boucle de vérification, car la prose ne peut pas être vérifiée automatiquement de manière approfondie. Forcer le modèle à produire une sortie structurée – même à un certain coût en ingénierie rapide – est la discipline qui rend l'automatisation en aval possible. La sortie structurée n’est pas seulement plus facile pour les machines ; c'est la condition préalable pour que les machines puissent aider à vérifier.

La bonne forme dépend de l'artefact. Pour un rapport, il peut s'agir d'un JSON validé par un schéma accompagné d'un document rendu. Pour un morceau de code, il s'agit du code lui-même ainsi que de ses signatures de type. Pour une image, c'est l'image et les métadonnées décrivant ce qu'elle représente. Pour un diagramme, c'est la source vectorielle plus une description. Le modèle est toujours le même – le formulaire destiné à l’homme est accompagné d’un formulaire vérifiable par machine – et le formulaire vérifiable par machine est ce sur quoi la boucle de vérification opère réellement.

Il existe une autre discipline concernant ce que devraient être les contrôles de vérification. Pas seulement structurel (le JSON est valide) mais sémantique (les valeurs du JSON ont du sens par rapport au domaine). Les vérifications d'un rapport peuvent inclure "les totaux sont rapprochés", "les catégories proviennent de l'ensemble connu", "aucun champ n'est vide alors qu'il ne devrait pas l'être". Les contrôles sémantiques sont ce qui détecte les erreurs manquées par les contrôles structurels, et ils ne sont possibles que lorsque la structure de l'artefact est suffisamment riche pour exprimer ce que « correct » signifierait.

Produisez des artefacts structurés. Vérifiez-les automatiquement. Incluez des contrôles sémantiques, pas seulement structurels. La boucle de vérification ne se ferme que lorsque l'artefact a une forme sur laquelle les contrôles peuvent opérer ; une sortie non structurée laisse la boucle ouverte, et les boucles ouvertes permettent aux erreurs de se glisser dans les travaux publiés.

Diagrammes sans sirène Slop

Les diagrammes de ce livre sont en SVG façonné à la main - coordonnées sur mesure, typographie délibérée, utilisation restreinte de l'accent - et je souhaite consacrer un chapitre à expliquer pourquoi, car l'alternative dominante pour les diagrammes générés par l'IA est la syntaxe Mermaid rendue dans un diagramme, et le résultat de ce pipeline est ce que j'en suis venu à considérer comme "Mermaid slop". Il ne s’agit pas d’une critique de l’outil Mermaid, qui est utile dans le bon contexte ; c'est une critique de l'utilisation de Mermaid comme substitut au design.

Le mode de défaillance spécifique de Mermaid slop est que chaque diagramme se ressemble. Mêmes rectangles arrondis, même palette par défaut, mêmes flèches disposées automatiquement, même typographie générique. L’outil résout le problème de dessin de manière si complète que le problème de conception – sur quoi ce diagramme doit-il mettre l’accent, sur quoi doit-il s’éloigner, où doit se poser l’œil – n’est jamais résolu du tout, car l’outil n’a jamais posé la question. Le résultat est un diagramme qui contient des informations mais sans voix éditoriale, et la voix éditoriale est ce qui rend un diagramme intéressant à regarder plutôt que simplement lisible.

L’alternative – SVG sur mesure, composé à la main – prend plus de temps par diagramme, et c’est dans le temps supplémentaire que réside la valeur. Décider de la couleur de l'accent. Décider quelle boîte est la boîte focale. Décider où la légende doit atterrir. Décider si un diagramme est vraiment nécessaire ou si un paragraphe ferait mieux l’affaire. Chacune de ces décisions est un petit acte de conception, et leur accumulation est ce qui transforme un livre de diagrammes en un livre que vous avez réellement envie de consulter.

L'angle de l'IA à ce sujet est que l'IA est très efficace pour produire la syntaxe Mermaid à la demande - dites « diagramme ceci » et elle produira une sirène syntaxiquement correcte qui décrit la forme. Ce qu'il ne fait pas bien, du moins pas sans une incitation minutieuse, c'est de produire des SVG sur mesure et sobres qui respectent un système de conception spécifique. Ainsi, la tentation, en particulier pour les pratiquants qui courent contre la montre, est d'accepter le résultat de Mermaid et de passer à autre chose. Cela produit des documents pleins de merde de sirène, qui communiquent tous à peu près les mêmes informations et dont aucun n'a de voix.

La discipline que j'utilise est que tout diagramme apparaissant dans un document que je publie est composé à la main par rapport au système de conception, même lorsque l'idée initiale provient d'un brouillon Mermaid généré par l'IA. Le brouillon de Mermaid est utile - il m'indique quelles cases et flèches sont nécessaires, quels nœuds sont focaux - mais le SVG final est composé par moi (ou par un modèle avec une invite très spécifique qui inclut les jetons de conception et les contraintes de retenue), non accepté tel que généré. Le temps supplémentaire par diagramme est réel ; la cohérence esthétique accumulée en vaut la peine.

Il existe un argument de goût plus large qui accompagne cela, à savoir que les outils d'IA ont tendance à produire un résultat qui correspond à la moyenne de leurs données d'entraînement, et que la moyenne de tout domaine créatif est médiocre. La conception en particulier est un domaine dans lequel le fait d'être moyen produit un résultat ennuyeux, et un résultat ennuyeux est ce que la plupart des diagrammes générés par l'IA ont en commun. Battre la moyenne nécessite soit un système de conception solide comme un échafaudage rapide, soit une composition manuelle – qui coûtent tous deux plus d'efforts que d'accepter la valeur par défaut. Cet effort supplémentaire est ce qui différencie les documents réfléchis des documents moyens.

Composez à la main les diagrammes qui apparaissent dans votre travail publié. Utilisez un système de conception sobre. Acceptez les brouillons de Mermaid comme des aides à la réflexion, et non comme des résultats finaux. Chaque diagramme qui vaut la peine d’être inclus mérite un laissez-passer supplémentaire ; tout ce qui ne vaut pas le pass supplémentaire ne vaut pas la peine d'être inclus.

Type Sécurité aux coutures

Lorsqu'une compétence transmet des données à une autre compétence, ou lorsque la sortie d'une exécution est réinjectée dans l'entrée de l'exécution suivante, l'interface entre elles est une couture. Les coutures sont l'endroit où les erreurs s'accumulent, car les deux côtés font des hypothèses sur ce qui se trouve de l'autre côté, et une petite dérive dans l'une ou l'autre hypothèse produit des bugs subtils. La sécurité des frappes au niveau des coutures (faire en sorte que les données traversant une couture aient la forme attendue par les deux parties) est l'une des disciplines les plus importantes que j'ai adoptées.

Le schéma de défaillance sans sécurité de type est familier. La compétence A produit un objet avec certains champs. La compétence B consomme un objet avec certains champs. Les deux travaillent de manière isolée. Quelqu'un modifie A pour ajouter un nouveau champ ou renommer un champ existant, ne pense pas à vérifier ce qui dépend de A, et B s'arrête à un moment ultérieur lorsque le cas limite exact est atteint. La rupture est subtile car la sortie de A semble à peu près correcte et l'échec de B ressemble au propre bug de B, donc la cause première prend des heures à isoler.

La sécurité des types à la couture fait passer cet échec d’un crash d’exécution à une erreur au moment de la compilation – ou au moment de la construction. La couture déclare formellement sa forme : A promet d'émettre un objet avec ces champs de ces types ; B déclare qu'il attend un objet avec ces champs. Toute incompatibilité est détectée avant l'exécution du code, au moment où l'incompatibilité est introduite. L'élément spécifique à l'IA est que lorsque le modèle produit du code qui franchit une couture, la vérification de type agit comme une vérification automatique de la sortie du modèle - le modèle ne peut pas émettre quelque chose qui ne correspond pas à l'interface sans que le vérificateur de type s'en aperçoive.

La discipline consiste à tracer des coutures explicitement, partout où les données franchissent une frontière. Entre compétences. Entre le runtime et sa persistance. Entre le frontend et le backend. Entre l'agent et ses outils. Chacune de ces limites mérite un type explicite – un schéma, une définition d’interface, un type au niveau du langage – sur lequel les deux parties conviennent. La quantité de travail de l'IA pour maintenir ces types est insignifiante ; la quantité de travail nécessaire pour détecter les erreurs qu’ils évitent est énorme.

Le mécanisme qui rend cela pratique réside dans les types peu coûteux à définir et à vérifier. Dans les bases de code, j'utilise TypeScript ou la bibliothèque de saisie de Python ; dans les situations de croisement de données, j'utilise des schémas JSON ou des définitions protobuf. Ce qui compte, ce n'est pas la technologie spécifique, c'est que la couture ait une forme formelle par rapport à laquelle les deux côtés peuvent être vérifiés, et la vérification est automatique. La documentation manuelle des interfaces n'a jamais fonctionné dans les bases de code que j'ai regardées ; la vérification automatique du type l'a toujours été.

Il existe un piège spécifique à l’IA qui mérite d’être nommé. Lorsqu'un agent produit une sortie structurée qui est transmise à un outil en aval, la sortie de l'agent doit être validée par le schéma avant d'être transmise à l'outil. Non pas parce que l'agent ment, mais parce que l'agent peut produire un résultat presque correct d'une manière qui fera planter l'outil dans des cas extrêmes spécifiques. La validation au niveau de la couture les détecte avant qu'ils ne se propagent, et il peut être demandé au modèle de se régénérer par rapport au schéma jusqu'à ce qu'il soit conforme. La couture est ce qui rend l’utilisation des outils agentiques sûre à grande échelle.

Dessinez des types à chaque couture. Appliquez-les automatiquement. Validez les sorties du modèle avant de franchir la couture. Les types sont le mécanisme qui transforme les interfaces de convention en contrat ; sans eux, chaque couture est un accident qui attend de se produire au moment le moins opportun.

Le laissez-passer de révision

Avant que tout ce que je produis soit expédié à un client, il fait l'objet d'une révision spécifique - une relecture structurée dans le but de rattraper tout ce que l'écriture initiale a manqué. Le passage prend quinze à trente minutes pour la plupart des artefacts, et c'est l'étape d'amélioration de la qualité la plus fiable dont je dispose. Le sauter semble efficace ; le faire permet de gagner plus de temps que cela n’en coûte, à chaque fois.

Le pass a une structure spécifique que j'ai affinée au fil des années. Première lecture : l’argumentation est-elle cohérente ? Chaque paragraphe découle-t-il du précédent et l’ensemble se construit-il quelque part ? Deuxième lecture : les détails sont-ils corrects ? Chaque fait cité, chaque chiffre, chaque affirmation concernant le produit. Troisième lecture : le ton est-il bon ? Est-ce que cela me ressemble, dans le registre attendu par le public, sans tomber dans le langage corporate ou la désinvolture artificielle ? Quatrième lecture : que manque-t-il ? Quelle question un lecteur intelligent poserait-elle sans réponse ici ?

La structure en quatre lectures est importante car elle sépare les préoccupations qui se confondraient en une seule lecture. Lorsque je lis par souci de cohérence, je ne me laisse pas distraire par des questions factuelles. Quand je lis des faits, je n’évalue pas le ton. Chaque passe est focalisée sur un seul objectif, ce qui me permet de réellement remarquer les problèmes spécifiques recherchés par la passe. Un seul passage du type « laissez-moi simplement le lire » a tendance à tout survoler, car l'attention n'est pas suffisamment étroite pour saisir quelque chose de spécifique.

La discipline entre les passes compte autant que les passes. Je ne fais pas les quatre en une seule séance. Je fais la passe de cohérence, je dépose le document pendant au moins quelques heures, je reviens pour la passe de faits, je le repose à nouveau, et ainsi de suite. Ce sont les lacunes qui me permettent de voir le document à jour à chaque passage ; une révision continue hérite de la fatigue de la passe précédente et devient progressivement moins utile. Mieux vaut moins de passes avec de vrais écarts que plus de passes consécutives.

L'angle de l'IA à ce sujet est que l'IA peut aider avec les passes mais ne devrait pas les remplacer. Un modèle peut signaler des erreurs factuelles probables, suggérer des améliorations structurelles, signaler des problèmes de ton – autant d’informations utiles. Ce que le modèle ne peut pas faire, c'est juger si le document répond réellement à son objectif pour le public spécifique, s'il dit ce que j'avais l'intention de dire, si l'accent est mis correctement. Ces jugements restent les miens, et les passes sont là où je les fais.

Le mode d'échec de l'omission de la révision est que la version d'un document au jour de l'expédition est presque toujours sensiblement pire que la version que j'aurais expédiée si j'avais effectué les passes. Pas catastrophiquement pire – les différences sont généralement faibles – mais systématiquement présentes, et elles s’aggravent dans de nombreux documents dans un arrière-plan de aspérités évitables. Les clients remarquent, inconsciemment, quand le travail qu'ils reçoivent a été examiné ou non ; la version révisée semble réfléchie, la version non révisée est adéquate.

Quatre passes ciblées, espacées dans le temps. Question différente par passe. Utilisez l’IA comme entrée, pas comme remplacement. C'est lors de l'évaluation qu'un travail compétent devient délibérément un bon travail, et la différence entre les deux réside dans la base des relations durables avec les clients.

Tests de propriété pour les invites

Les tests traditionnels vérifient que des entrées spécifiques produisent des sorties spécifiques. Les tests de propriétés vérifient que toute entrée satisfait à certaines propriétés : la sortie est toujours triée, toujours non vide, toujours dans un état valide. Pour le code, les tests de propriétés sont une discipline mature. Pour les invites, elles sont sous-utilisées et sont particulièrement bien adaptées au travail d'IA, car les invites fonctionnent de manière probabiliste et les tests d'entrée spécifiques peuvent échouer par chance tout en manquant de larges classes d'échec.

Le modèle qui a motivé cela pour moi était de regarder les invites qui transmettaient les exemples spécifiques contre lesquels je les avais testés, qui échouaient de manière prévisible sur des entrées que je n'avais pas spécifiquement vérifiées. L'invite "a fonctionné" sur mes dix exemples et s'est interrompue le onzième, et le onzième était structurellement similaire à l'un des dix d'une manière qui aurait dû le faire fonctionner. Ce qui manquait, c'était un test de la propriété « pour les entrées de cette forme, la sortie doit toujours satisfaire X » – et non un test de paires entrée-sortie spécifiques.

Le mécanisme consiste à générer de nombreuses entrées de la classe qui vous intéresse - soit à partir d'une distribution réelle, soit à partir d'une distribution synthétique conçue pour couvrir les cas extrêmes - exécutez chacune via l'invite et vérifiez les sorties par rapport aux propriétés dont vous avez besoin. La propriété peut être structurelle (chaque sortie a le même schéma), sémantique (chaque sortie se situe dans une plage de valeurs valide) ou comportementale (la sortie change de manière appropriée lorsque des aspects spécifiques de l'entrée changent). Ce qui compte, c'est que la propriété soit indiquée de manière suffisamment précise pour être vérifiée automatiquement sur de nombreux échantillons.

Les tests de propriétés sont particulièrement utiles pour détecter les régressions de modèle du type décrit au chapitre 66. Lorsqu'un modèle est mis à jour et que les sorties spécifiques changent légèrement mais que les propriétés sont toujours valables, votre système continue de fonctionner ; lorsque les propriétés cessent de fonctionner, le test de propriété se déclenche immédiatement, avant qu'un client ne voie la régression. Ceci est qualitativement différent des tests basés sur des exemples, qui réussissent ou échouent en fonction de l'identité : un changement de sortie qui préserve la propriété est un faux échec pour les tests d'exemple et, à juste titre, une réussite pour les tests de propriété.

Le mode d’échec des tests de propriétés est qu’ils sont aussi bons que les propriétés que vous pensez vérifier. Un test de propriété qui vérifie uniquement « la sortie n'est pas vide » détecte uniquement l'échec « sortie vide » ; tout ce qui lui manque. Ainsi, la conception des propriétés est le lieu où réside l'intelligence, et elle est itérative : commencez par les propriétés évidentes, surveillez les échecs qui subsistent, ajoutez des propriétés pour les détecter. Au fil du temps, la suite de propriétés converge vers quelque chose qui détecte la plupart des classes de défaillances, et les défaillances restantes sont celles que les propriétés n'auraient véritablement pas pu prédire.

Il y a une dimension de coût qui mérite d’être mentionnée. L'exécution d'un test de propriété sur de nombreux échantillons coûte de nombreux appels de modèle. Pour une invite spécifique envoyée en production, ce coût est bien justifié ; pour les travaux exploratoires, cela pourrait être exagéré. Ma règle de travail est que toute invite envoyée à un engagement client obtient une suite de propriétés ; les invites exploratoires ne le font pas. La barre pour « expédition » ici n'est pas « en production » mais « devrait fonctionner de manière fiable par rapport à des entrées que je n'ai pas personnellement vues » – ce qui correspond à la plupart des invites adressées aux clients.

Écrivez les propriétés des invites d'expédition. Échantillon à partir de distributions réalistes. Surveillez les échecs et ajoutez des propriétés pour les cours que vous avez manqués. Les tests de propriété sont ce qui transforme « l'invite fonctionne sur mes exemples » en « l'invite fonctionne sur la classe d'entrées qu'elle verra réellement », ce qui est une affirmation beaucoup plus forte.

Envoyer une source de vérité

Chaque système client de longue durée que je construis a finalement besoin d'une source de vérité - un endroit spécifique où réside la réponse canonique à « quel est l'état actuel », de sorte que les consommateurs en aval, les tableaux de bord, les exportations et les rapports pointent tous vers la même réalité sous-jacente. Décider quelle est cette source et défendre son autorité contre les alternatives tentantes est un travail spécifique sur lequel il vaut la peine de consacrer un chapitre.

Le mode de défaillance que j'ai observé le plus souvent est celui des systèmes comportant deux ou trois sources censées s'accorder et qui ne le sont pas. Une base de données et un cache. Un magasin opérationnel et un magasin de reporting. Une API live et un export nocturne. Deux de ces désaccords produisent la même confusion : lequel a raison ? - et la réponse est souvent "ni l'un ni l'autre, exactement, ils se sont tous deux éloignés de l'idéal de différentes manières au fil du temps". Le moyen d’éviter cela est de désigner d’abord l’une d’elles comme la source de la vérité, et d’en faire explicitement dériver les autres.

La source nommée a une autorité que les sources dérivées n'ont pas. Chaque écriture va d'abord à la source ; les magasins dérivés rattrapent la source. Chaque lecture qui nécessite de l'exactitude se lit à partir de la source ; les magasins dérivés servent des lectures où l'obsolescence est acceptable. Chaque référence de rapprochement est vérifiée par rapport à la source ; les désaccords entre les magasins dérivés sont résolus en examinant ce que dit la source. La source est l’arbitre et tout autre magasin est un lecteur en aval avec un rôle subordonné.

L’angle de l’IA est que les systèmes agents produisent beaucoup d’états – traces, artefacts, résultats intermédiaires – et il est tentant de les stocker dans ce qui convient à chaque étape. Sans une discipline de source de vérité, vous vous retrouvez avec la même trace résumée en trois endroits, chacun dérivé des autres, et aucun moyen de savoir lequel est canonique. La discipline consiste à désigner dès le départ un magasin faisant autorité (généralement le journal de trace lui-même) et à traiter tout le reste comme une dérivation que vous pouvez reconstruire à partir de celui-ci.

Le corollaire est que tout ce qui n’est pas à la source de la vérité ne compte pas. Si le tableau de bord agrégé affiche un numéro qui ne peut pas être reproduit à partir de la source, le numéro est erroné ; si un rapport contient un artefact dont la référence ne figure pas dans la source, l'artefact est sans état. C’est inconfortable au début, car cela signifie que vous ne pouvez pas tricher – chaque élément d’état affiché doit provenir d’un endroit légitime – et c’est précisément cet inconfort qui maintient les systèmes honnêtes. La tricherie produit une commodité à court terme et une dérive à long terme.

Le principe de conception sous-jacent est que la « cohérence » est une propriété d’un système avec un seul magasin faisant autorité ; ce n'est pas réalisable avec plusieurs magasins co-égaux. La littérature sur les systèmes distribués le sait depuis des décennies. Les systèmes d'IA héritent exactement de la même règle : choisissez votre magasin faisant autorité, faites en sorte que tout le reste soit dérivé, et le problème de cohérence devient résolu. Essayez d'avoir plusieurs sources de vérité et vous inventez votre propre version d'un problème résolu, et vous vous trompez de la même manière que les praticiens précédents l'ont fait.

Nommez la source. Dérivez tout le reste. Refusez d’afficher tout ce qui ne peut être retracé. La cohérence que vous obtenez n'est pas gratuite – elle nécessite de la discipline en matière d'écriture – et c'est la propriété qui transforme un ensemble de magasins en un système auquel vous pouvez faire confiance.

La vérification du ton

Chaque élément de contenu destiné au client passe un contrôle spécifique que j'appelle le contrôle de tonalité : lire le document à haute voix, ou presque à haute voix dans ma tête, en écoutant partout où la voix glisse. Parce que le ton est la pièce l'écriture augmentée par l'IA se trompe le plus souvent subtilement, et les clients remarquent que le ton glisse à un niveau inférieur à la conscience - ils ne disent pas "le ton était faux", ils repartent simplement avec un sentiment légèrement moins de confiance qu'ils l'auraient fait autrement.

Les glissements de ton spécifiques que je surveille sont les suivants. Changement soudain dans le langage de l'entreprise, où un document lu comme un humain commence soudainement à dire des choses comme « exploiter les synergies » ou « apporter de la valeur » sans raison. Une étrange désinvolture, où le document essaie de paraître amical et atterrit sur des débuts "hé, alors..." qui ne correspondent à rien d'autre dans la pièce. Sur-couverture, où chaque affirmation est accompagnée de trois mises en garde jusqu'à ce que le lecteur ne puisse plus comprendre ce qui est réellement dit. Voix passive bureaucratique, où « nous avons fait X » devient « X a été entrepris ». Chacun d’eux est petit et chacun d’eux nuit à la crédibilité.

La prose générée par l'IA est particulièrement sujette aux lapsus spécifiques que j'ai nommés, car la formation du modèle l'expose à d'énormes quantités de discours d'entreprise, d'écriture sur-couverte et de convivialité générique, et ces modèles sont faciles à adopter par défaut. Sans vérification délibérée du ton, le contenu produit par le modèle dérive vers la moyenne de ses données d'entraînement, et la moyenne n'est ni particulièrement bonne ni particulièrement distinctive. La moyenne neutre est le mode d’échec.

Le mécanisme que j'utilise est ennuyeux : lire le document, à voix haute si je peux, silencieusement si je ne peux pas, et noter chaque endroit où la voix semble différente de la façon dont je parle ou écris réellement. Chaque note devient une modification. Parfois, la modification est un mot — remplaçant « effet de levier » par « utilisation ». Parfois, il s'agit d'une phrase entière : remplacer une créance passive couverte par une créance directe. Parfois, c'est un paragraphe. Le résultat final est un document qui me ressemble, pas aux données d'entraînement.

La raison pour laquelle cela compte plus qu'il n'y paraît est que la cohérence de la voix est l'un des éléments spécifiques qui rendent l'écriture digne de confiance. Un document qui change de registre trois fois sur une page est choquant même lorsque le lecteur ne peut pas expliquer pourquoi ; un document qui conserve une voix cohérente semble être un auteur, même si la voix elle-même est banale. La paternité est un signal auquel les lecteurs réagissent à un niveau préconscient, et elle constitue la valeur de documents entiers constitués de décisions de petit ton.

Il existe une discipline spécifique pour l'édition du ton produit par le modèle sur laquelle je m'appuie : réécrivez les deux premiers paragraphes avec votre propre voix, sans aide, et utilisez-les comme référence tonale pour éditer le reste. Les deux premiers paragraphes ancrent les attentes du lecteur pour l'ensemble de l'article, et s'ils sont cohérents dans votre voix, le reste du document doit correspondre ou la disparité est visible. Cela fait plus pour fixer le ton de l'ensemble du document que n'importe quelle invite générale « faites-le ressembler davantage à moi » au modèle.

Lisez pour le ton. Attrapez les feuillets spécifiques. Ancrez avec vos propres paragraphes d’ouverture. La cohérence de la voix n’est pas décorative ; c'est le substrat sur lequel se construit la crédibilité, et l'écriture augmentée par l'IA a encore plus besoin de vérifier le ton que l'écriture manuscrite pure.

Red-Teaming votre propre sortie

La partie IX se termine sur la discipline de vérification la plus inconfortable : attaquer délibérément votre propre travail, rechercher les façons dont il pourrait être erroné, mal interprété ou exploité. Faire équipe en rouge avec votre propre production est désagréable, car cela nécessite de maintenir la position selon laquelle ce que vous avez créé est potentiellement défectueux, exactement au moment où vous aimeriez avoir la certitude que ce n'est pas le cas. Le faire de toute façon est ce qui différencie les praticiens qui détectent leurs propres erreurs de ceux dont les erreurs doivent être détectées par les clients.

La pratique spécifique consiste à se demander, pour chaque résultat significatif : comment cela pourrait-il mal se passer ? Non pas « est-ce que ça va mal tourner » – c’est une question de défensive – mais « comment ça pourrait mal tourner », qui est une question de créativité. Si j'essayais de briser cela, de le mettre dans l'embarras, de l'interpréter mal, d'extraire quelque chose qu'il ne devrait pas révéler, que ferais-je ? Les réponses à ces questions sont les vulnérabilités de la sortie, et les trouver vous-même coûte considérablement moins cher que de les faire trouver par quelqu'un d'autre.

Les attaques spécifiques à l'IA qui méritent d'être citées incluent l'extraction rapide (Chapitre 67), produisant un résultat révélant des informations sensibles sur la formation ou le système, et produisant un résultat qu'un utilisateur pourrait sortir de son contexte d'une manière qui entraînerait des problèmes en aval. Chacun d'eux est une classe de défaillance que des entrées spécifiques peuvent déclencher, et les tests par rapport à ces entrées avant l'expédition sont ce qui transforme un système « nous espérons que personne ne pense à essayer cela » en un système « nous avons essayé cela et confirmé qu'il est géré ».

La discipline doit être véritablement contradictoire. Il ne suffit pas de tenter quelques attaques évidentes et de déclarer le système sûr ; vous devez réellement essayer de le briser, comme le ferait un adversaire intéressé. Ceci est inconfortable car cela nécessite de mettre de côté votre identification au système et de le traiter comme le ferait un adversaire. Les pratiquants qui ne peuvent pas opérer ce changement mental rateront des classes d'échec qu'un véritable adversaire ne manquera pas, et l'écart sera payé au pire moment possible.

Le mécanisme que j'utilise est une petite "liste de contrôle de l'équipe rouge" par système déployé, mise à jour à mesure que de nouvelles classes d'attaque apparaissent. Extraction rapide : est-ce que ça marche ? Essayez quelques techniques d’extraction et voyez. Tentatives de jailbreak : le système reste-t-il opérationnel face à des invites contradictoires ? Essayez les modèles de jailbreak courants. Violations des limites : le système refuse-t-il les demandes qu'il devrait refuser, proprement ? Essayez les requêtes proches et au-delà de la limite. Chacun d'eux est un test spécifique, et chaque vulnérabilité détectée est une vulnérabilité spécifique qu'un utilisateur réel ne sera pas celui qui trouvera.

Il y a un principe plus large sous-jacent, à savoir que la plupart des vulnérabilités des systèmes d’IA sont des catégories connues, et que l’application d’une réflexion sur les catégories connues est ce qui les détecte à moindre coût. L'entrée spécifique qui extrairait une invite sur votre système est inconnue ; la forme générale des attaques par extraction rapide est bien documentée et facile à tester. Testez la forme et vous détecterez l'instance spécifique, sans avoir besoin d'énumérer toutes les attaques possibles.

Le dernier élément est l’honnêteté de ce que vous trouvez. Si l'équipe rouge révèle une vulnérabilité réelle, corrigez-la avant l'expédition – n'expédiez pas et n'espérez pas. S'il révèle quelque chose que vous ne pouvez pas entièrement réparer mais que vous pouvez partiellement atténuer, envoyez l'atténuation et indiquez au client ce qui reste. L’équipe rouge qui fait apparaître les problèmes puis les cache met à mal la discipline ; le red-teaming qui agit sur ce qu'il trouve est que la discipline fonctionne correctement.

Demandez comment cela pourrait mal tourner. Essayez de le casser. Réparez ce qui casse. Expédiez avec les vulnérabilités que vous avez trouvées délibérément fermées, et non avec celles que vous auriez pu trouver encore ouvertes. Le client qui n’a jamais à découvrir vos vulnérabilités est le client dont vous gardez la confiance.

La composition du jour au lendemain comme effet de levier

Les disciplines décrites dans ce livre sont payantes individuellement : un meilleur registre, un adaptateur plus propre, une simulation plus disciplinée. Là où ils rapportent de façon exponentielle, c'est là qu'ils s'accumulent, et la composition spécifique que je veux nommer est ce qui se produit lorsque le travail de nuit cesse d'être une astuce occasionnelle et devient le principal moyen par lequel le système produit de la valeur. La capitalisation du jour au lendemain est l’effet de levier vers lequel tout le livre s’est développé.

Le modèle est le suivant. Au cours de mes vingt heures actives par semaine, je prends des décisions, examine les résultats et informe la file d'attente de nuit. Pendant les plus d'une centaine d'heures d'inactivité par semaine, la file d'attente traite ce que j'ai briefé. Le rapport entre les heures actives et passives dans le système est d'environ un à cinq, ce qui signifie que chaque heure que je passe bien peut se transformer en cinq heures de travail en aval. Ce ratio s'aggrave : la production nocturne de chaque semaine se répercute sur les briefs de la semaine suivante, les améliorations de la qualité des briefs de chaque mois se combinent pour obtenir de meilleurs résultats en file d'attente.

La propriété essentielle est que la composition nécessite que chacune des disciplines soit présente. Sans l'opération sécurisée de nuit de la partie III, la file d'attente produit une sortie interrompue qui n'est pas utilisable. Sans le registre des coûts de la Partie IV, la file d'attente produit une production coûteuse dont vous ne pouvez pas vérifier les aspects économiques. Sans l'ensemble des compétences de la partie V, la file d'attente produit des exécutions ponctuelles qui ne s'appuient pas les unes sur les autres. Sans la passe de vérification de la partie IX, la file d'attente produit un résultat auquel vous ne pouvez pas faire confiance. Chaque partie du livre est une condition nécessaire à la composition ; il manque l'un d'entre eux et l'effet de levier ne se matérialise pas.

Le système qui émerge lorsqu’ils sont tous présents n’est pas le fantasme de « l’IA fait tout ». Il s'agit d'une configuration spécifique à l'échelle humaine dans laquelle l'attention de l'humain est consacrée aux éléments que seule l'attention humaine peut faire – le jugement stratégique, la relation avec le client, l'évaluation du goût – et le débit mécanique est délégué. Ceci est proche de l’arrangement que les bonnes opérations pré-IA essayaient de réaliser avec des équipes humaines, mais à moindre coût et avec une meilleure observabilité. La nouveauté, c'est l'économie ; le modèle est ancien.

La leçon qui mérite d’être citée est que l’effet de levier de ce type est une construction lente et non un retournement soudain. Il m'a fallu des années d'application progressive de ces disciplines avant que la composition ne devienne perceptible, et il y a eu de longues périodes où chaque pratique individuelle ressemblait à un travail supplémentaire avec des résultats incertains. La composition ne s'annonce pas; il s'accumule tranquillement. Les pratiquants qui abandonnent les disciplines parce que les gains individuels sont faibles n’atteignent jamais la zone de capitalisation, où les petits gains individuels se multiplient en quelque chose de plus grand.

L’autre leçon concerne la limite de l’effet de levier. La composition via le travail de nuit est réelle, mais elle n'est pas illimitée. Le plafond est fixé par la qualité des briefs que je peux produire, l’honnêteté de l’avis que je peux donner et la cohérence de l’orientation stratégique que je peux tenir. Chacune de ces capacités est une capacité humaine qui ne peut pas évoluer avec davantage de calcul. La machine peut amplifier ce que je fais bien ; cela ne peut pas remplacer ce que je fais mal. Ce qui signifie que l’effet de levier s’exerce sur un substrat de compétence humaine – et l’amélioration de ce substrat constitue l’investissement le plus rentable au-delà d’un certain point.

Construisez toutes les disciplines. Regardez-les s’accumuler au fil des années, pas des mois. Reconnaissez que le plafond de l’effet de levier réside dans la capacité humaine en dessous ; continuez à investir là-bas aussi. Le système qui s’exécute lui-même ne fonctionne pas sans l’humain pour lequel il fonctionne.

La ligne de frappe de Crontab

La blague que je suis venu raconter à propos de l'ensemble du système est que la majeure partie de ma carrière est tranquillement devenue une crontab Unix. Pas une métaphore : une véritable crontab, sur un serveur réel, avec des entrées planifiées qui se déclenchent tous les soirs et tous les matins et une fois par heure et tous les dimanches à 6 heures du matin, exécutant les flux de travail automatisés spécifiques qui produisent la plupart des résultats mécaniques que mes clients voient. La crontab est la ligne directrice de l'argumentation complexe du jour au lendemain, et l'énoncer clairement mérite un chapitre, car c'est la clarté qui surprend les gens.

Ce qu'il y a dans la crontab n'est pas glamour. Un travail de nuit qui génère les rapports dont dépendent plusieurs clients. Un travail matinal qui vérifie les résultats de la nuit et me prévient en cas d'échec. Un travail hebdomadaire qui rapproche les grands livres conformément au chapitre 40. Un travail horaire qui surveille les événements externes auxquels je dois répondre. Un travail mensuel qui produit le résumé que chaque client reçoit. Aucun de ces éléments n’est compliqué en soi ; chacun d'eux, avant que cet arrangement n'existe, aurait représenté une heure de mon temps un jour spécifique de la semaine ou du mois, et maintenant il s'agit d'une entrée programmée qui s'exécute pendant que je fais autre chose.

La raison pour laquelle "juste une crontab" est une punchline est que les gens s'attendent à ce que l'effet de levier décrit dans ce livre nécessite quelque chose de plus sophistiqué. Plateformes d'orchestration. Moteurs de flux de travail. Clusters Kubernetes. Le mécanisme réel, pour la majeure partie de mon automatisation, est une primitive de planification qui existe depuis les années 1970, permettant une planification simple des tâches, sans aucune innovation. L'effet de levier n'est pas dans le planificateur ; c'est dans le travail que le planificateur planifie. Cron est un mécanisme ; l'effet de levier est une discipline.

La leçon à en tirer est architecturale. Lorsqu'un flux de travail doit s'exécuter selon un calendrier, la bonne question n'est pas « quelle plateforme de planification sophistiquée dois-je adopter » mais « dans quelle mesure la planification peut-elle être simple tout en continuant à faire le travail ». Pour la plupart de mes besoins, cron plus un script bien conçu et une alerte de surveillance suffisent - et suffisant bat sophistiqué à chaque fois, car suffisant est une chose de moins à maintenir, sécuriser et à consulter. Les outils simples qui fonctionnent pendant des décennies valent plus que ceux à la mode qui nécessitent un entretien constant.

Le mode d’échec que je souhaite éviter de nommer en règle générale est que les flux de travail planifiés peuvent pourrir silencieusement. Une tâche cron qui fonctionnait auparavant peut cesser de fonctionner - l'API qu'elle appelle a déménagé, le script a un problème d'environnement, le magasin de sortie manque d'espace - et personne ne le remarque car cron continue joyeusement d'exécuter la tâche et continue joyeusement d'enregistrer les échecs. La discipline qui sauvegarde cela est la trace du chapitre 18 : chaque exécution planifiée émet sa trace, une couche de surveillance surveille ces traces et toute exécution qui ne se termine pas correctement déclenche une page. Un échec silencieux est ce qui transforme une crontab fonctionnelle en une crontab vieillissante ; l’échec surveillé est ce qui le maintient honnête.

Le goût spécifique qui mérite d'être mentionné est que les entrées crontab doivent être lisibles par la personne qui doit les corriger à 3 heures du matin, ce qui est souvent moi et pourrait un jour être quelqu'un d'autre. Des entrées bien commentées. Noms de scripts descriptifs. Des variables d'environnement qui ont du sens. La crontab d'un système bien organisé se lit comme une documentation de ce que le système fait réellement selon un calendrier, ce qui représente une grande partie de ce qu'il fait. Les crontabs bâclés se lisent comme un mystère ; les mystères bâclés sont ce qui se brise aux moments inopportuns.

Utilisez la planification la plus simple qui fonctionne. Surveillez les traces. Commentez les entrées. Et laissez "juste une crontab" être la ligne directrice de votre système, car si l'effet de levier vient réellement de la discipline derrière le calendrier, celui-ci peut se permettre d'être ennuyeux.

Déléguer à votre propre machine

Il y a un changement dans la façon dont vous considérez votre propre ordinateur portable ou votre propre serveur, lorsqu'il cesse d'être un outil que vous utilisez et commence à être un collègue à qui vous déléguez. Ce chapitre porte sur ce changement, car il change ce que vous attendez de la machine et ce que vous êtes à l'aise de lui demander, et il m'a fallu plus de temps que prévu pour faire la transition.

L’ancien modèle est que l’ordinateur portable est un espace de travail – un endroit où je travaille, en utilisant des outils qui se trouvent sur la machine. Dans ce modèle, lorsque je ferme l'ordinateur portable, le travail s'arrête. Rien ne fonctionne quand je ne suis pas là ; rien n’est nécessaire ; la machine est entièrement sous mon utilisation active. C'est ainsi que j'ai utilisé les ordinateurs pendant les quinze premières années de ma carrière, et c'était le bon modèle à l'époque : les machines n'étaient pas assez rapides ni assez puissantes pour mériter d'être déléguées, et il n'y avait rien à déléguer.

Le nouveau modèle est que la machine est une collègue. Quelque chose sur lequel je peux confier le travail, m'attendre à ce qu'il soit terminé pendant que je suis ailleurs et vérifier à mon retour. Lorsque je ferme l'ordinateur portable – ou plus probablement, lorsque je ferme mon éditeur actif – le travail ne s'arrête pas. Les exécutions programmées font feu. Les pipelines automatisés s'exécutent. Traitement par lots de nuit. Les heures d'activité de la machine ne sont pas les mêmes que mes heures d'activité, et c'est dans cette asymétrie que réside réellement l'effet de levier du chapitre 91.

Le changement mental est inconfortable au début. Faire confiance à un travailleur délégué nécessite d'être capable d'inspecter ce qu'il a fait après coup, d'être sûr qu'il demandera de l'aide en cas de blocage et d'être d'accord avec lui pour prendre des décisions en votre absence. Appliqué à une machine, cela signifie un bon traçage, de bonnes alertes et des scripts bien conçus qui échouent bruyamment lorsqu'ils ne peuvent pas continuer. Chacun de ces éléments a été abordé plus tôt dans le livre ; le changement mental consiste à les rassembler et à faire réellement confiance au résultat.

Le mode d’échec de ce changement est que les praticiens dotés d’outils améliorés par l’IA travaillent toujours comme s’ils étaient dans l’ancien modèle : utilisation active uniquement, fermez l’ordinateur portable et rien ne se passe. Ils peuvent exécuter manuellement des lots occasionnels et les appeler automatisation, mais le rôle de la machine reste celui d'un outil utilisé par un humain actif. La composition préconisée dans ce livre ne se produit pas dans ce modèle, car les heures supplémentaires de débit ne sont jamais réellement réclamées. La machine pourrait faire plus ; on ne le demande pas.

Le mode d’échec d’un mauvais changement est de faire trop confiance à la machine, trop tôt. Déléguer le travail avant que le traçage, la surveillance et le traitement des erreurs ne soient en place produit l'opposé d'un effet de levier : des pannes non détectées s'accumulent du jour au lendemain, découvertes uniquement lorsqu'un client se plaint. La confiance dans la machine doit être gagnée grâce aux disciplines qui rendent la délégation sûre, et une délégation prématurée est ce qui enseigne aux praticiens que « l'automatisation ne fonctionne pas », alors qu'ils ont automatisé sans filet de sécurité.

La synthèse est que la machine peut être un excellent collègue dans des conditions spécifiques, et ces conditions sont exactement celles pour lesquelles ce livre a défendu tout au long. Construisez le traçage. Construisez la surveillance. Construisez la classification des échecs. Construisez le grand livre. Une fois ceux-ci en place, la délégation est sûre ; avant qu'ils ne soient en place, c'est imprudent. Effectuer un changement de mentalité n’est donc pas seulement une question de confiance, il s’agit également de gagner la confiance sur laquelle repose la confiance.

Traitez la machine comme un collègue lorsqu'elle mérite le traitement. Déléguez ce qu’il peut honnêtement gérer. Vérifiez-le via les traces, pas en survolant. L’effet de levier vient du fait que la délégation est réelle, et la délégation est réelle vient du fait que le filet de sécurité est réel. Les deux, ou ni l’un ni l’autre.

Que reste-t-il à l'humain

Si la machine effectue le travail mécanique, effectue le traitement pendant la nuit, produit les artefacts et respecte le calendrier, que me reste-t-il à faire ? La question semble simple, mais je la prends au sérieux, car si la réponse honnête est « de moins en moins », cela a des implications sur la façon dont je planifie la prochaine décennie de ma carrière. Ma réponse de travail, après des années d'observation de ce qui se passe réellement, est que le rôle de l'humain se rétrécit mais ne disparaît pas ; il se concentre davantage sur un travail spécifique que seuls les humains peuvent effectuer.

En fait, ce à quoi je consacre mon temps maintenant, pendant les heures humaines, ce sont ces choses-là. Jugement stratégique – quels clients prendre en charge, quels problèmes résoudre, quelles formes d’engagement poursuivre. Relation – le contact humain direct avec les clients, la lecture de ce dont ils ont réellement besoin sous ce qu'ils disent. Conception - les décisions au niveau du goût sur ce à quoi devrait ressembler le résultat, quelle structure devrait avoir un système, à quoi ressemblerait un bon résultat. Révision - l'acte de fusion matinale consistant à juger ce que la machine a produit et à décider quels navires. Enseigner : aider mes collègues, mes clients et mes lecteurs à apprendre des choses que je sais et qu'ils ignorent.

Aucun d’entre eux n’a été automatisé de manière convaincante, et je ne m’attends pas à ce que la progression à court terme de l’IA change cela de manière significative. Le jugement stratégique nécessite un contexte accumulé au fil des années et appliqué à des situations nouvelles. La relation nécessite d'être réellement une personne en contact avec une autre personne. Le design au niveau du goût nécessite le sens esthétique d’un humain qui se soucie d’un public spécifique. L'examen nécessite d'avoir le droit de dire « oui, expédier » ou « non, de refaire » et d'être digne de confiance dans les deux cas. Enseigner nécessite d'avoir réellement vécu ce que vous enseignez.

Ce qui est intéressant, c’est que les heures humaines, dans cet arrangement, sont plus compressées qu’auparavant. Lorsque le travail mécanique est délégué, le travail restant est plus dense : plus de décisions stratégiques par heure, plus de relations clients par heure, plus de révisions par heure. Cela signifie que la même semaine de vingt heures produit beaucoup plus de ce qui compte réellement, mais cela signifie également que ces vingt heures sont plus intenses que ne l'étaient quatre-vingts heures diluées de travail avant l'IA. L'effet de levier ne réduit pas l'effort ; il le concentre sur une activité à plus haut rendement, qui est souvent plus fatigante par heure.

Le corollaire est que le travail humain bénéficie d'investissements que le travail mécanique n'a pas bénéficié. Si les heures humaines sont celles qui ont de la valeur, alors l'amélioration des capacités humaines – lecture, réflexion, goût, jugement – ​​est l'investissement le plus rentable au-delà d'un certain point. Investir dans une automatisation plus sophistiquée rapporte des rendements décroissants lorsque l’automatisation est déjà bonne ; investir dans l’humain qu’il augmente continue de payer. C'est le cas spécifique des heures humaines consacrées en partie au développement de l'humain, et non seulement à l'exécution de tâches.

Il y a un point philosophique plus large qui mérite d’être souligné. La crainte que l’IA rende le travail humain obsolète suppose que le travail humain était au départ fongible avec le travail des machines. Dans la pratique spécifique décrite dans ce livre, ce n'était pas le cas - les heures humaines faisaient toujours quelque chose de différent des heures mécaniques, et les heures mécaniques devenant moins chères ne changent pas à quoi servaient les heures humaines. Ce qui change, c'est le ratio, qui rend la contribution spécifique de l'humain plus visible et plus précieuse, et non la moindre.

Ce qui reste à l’humain n’est pas moindre qu’avant. C’est plus concentré, plus précieux, plus exigeant et plus crucial pour savoir si l’ensemble du système produit quelque chose qui en vaut la peine. C’est l’avenir que le livre décrit depuis le début ; la crontab effectue le travail mécanique tandis que l'humain effectue le travail spécifiquement humain, et les deux sont essentiels au résultat.

Quand enseigner la machine

Parfois, la réponse honnête à une tâche répétée est de développer une compétence pour celle-ci, et parfois la réponse honnête est de continuer à la faire à la main pendant un cycle supplémentaire. Décider lequel est une question de jugement spécifique, et je souhaite consacrer un chapitre à ce que j'y pense, car "dois-je automatiser cela" est une question qui revient plusieurs fois par semaine et obtenir une mauvaise réponse dans un sens ou dans l'autre coûte cher.

La réponse naïve est « toujours automatiser ». Toute tâche répétitive mérite une compétence. C'est faux, car le calcul du seuil de rentabilité du chapitre 35 montre qu'il existe un seuil : les tâches récurrentes avec trop peu d'instances ne rapportent pas leur coût d'automatisation et le temps de configuration est perdu. La réponse naïve optimise le mauvais horizon ; il considère l'automatisation comme gratuite, et ce n'est pas le cas.

La réponse contre-naïve est « ne jamais automatiser ; le travail manuel est acceptable ». C’est faux car les tâches dont le coût réel est une petite répétition manuelle finissent par prendre beaucoup de temps, en particulier dans une pratique solo aux horaires limités. Le praticien manuel accumule une charge de fond de petites tâches répétitives qui auraient pu être supprimées par l'automatisation, et la charge dépasse finalement sa capacité à développer davantage sa pratique. Refuser d’automatiser par principe crée un goulot d’étranglement en forme de carrière.

La bonne réponse se situe entre les deux et nécessite un jugement au cas par cas. Mes heuristiques de travail sont les suivantes. Si une tâche est récurrente selon un planning fixe (hebdomadaire, mensuel), automatisez-la dès qu'elle est bien définie, car la récurrence est garantie. Si une tâche est récurrente à la demande, attendez de l'avoir effectuée trois à cinq fois à la main, car d'ici là, le modèle de variation n'est pas suffisamment clair pour être automatisé. Si une tâche est unique mais que sa forme peut être récurrente (un rapport spécifique pour un client que d'autres clients pourraient vouloir), la première étape honnête consiste à bien rédiger la version manuelle et à voir si la forme est réellement demandée à nouveau avant d'investir dans une compétence.

Il y a un modèle spécifique à surveiller qui aide à décider. Lorsque j'effectue une tâche manuelle et que je me retrouve à penser « Je sais que j'ai déjà fait cela mais je ne me souviens pas exactement comment », c'est souvent le signal que la tâche est plus répétitive que je ne l'ai traitée. Un moment de reconnaissance des instances antérieures est un moment de réflexion sur une compétence. L’alternative – reconstruire l’approche à partir de zéro à chaque fois – est une forme de coût caché que le mode manuel permanent rend invisible.

L’autre modèle qui mérite d’être cité est l’émergence d’une forme partagée entre plusieurs tâches. Lorsque deux ou trois tâches que j'avais traitées comme ponctuelles commencent à ressembler à des instances de la même compétence - mêmes intrants, même forme approximative, même catégorie de résultat - cette convergence est le moment où la compétence sous-jacente veut exister. Construire une compétence qui sert aux trois tâches coûte moins cher que construire trois compétences et produit souvent une capacité plus générale qui détecte automatiquement les futures tâches similaires.

Apprenez à la machine quand la récurrence est réelle, quand vous avez vu la forme suffisamment de fois pour avoir une opinion à ce sujet et quand la version manuelle commence à ressembler à un coût invisible. Ne l’enseignez pas trop tôt – vous vous fonderez sur de fausses hypothèses. N'attendez pas trop longtemps, vous paierez la taxe manuelle indéfiniment. Le bon moment est une question de jugement, et bien faire les choses devient une partie de l’intuition qui se développe au fil des années de gestion du cabinet.

Succession

Ce chapitre traite d'une question que je trouve inconfortable mais que j'ai commencé à prendre au sérieux : qu'arrive-t-il au système décrit dans ce livre lorsque ce n'est pas moi qui le gère ? Non pas parce que j'ai l'intention d'arrêter bientôt – ce n'est pas le cas – mais parce qu'une pratique qui ne fonctionne qu'avec une seule personne spécifique au centre est une pratique fragile, et la fragilité doit être conçue contre.

La réponse naïve est que la succession n'est pas un problème car une pratique solo est par définition liée au praticien solo. S'ils s'arrêtent, ça s'arrête. Mais ce n’est pas tout à fait vrai, et il est instructif de réfléchir aux raisons pour lesquelles ce n’est pas vrai. Les relations clients, les clients de référence, la réputation, tout cela est transférable à un successeur, s'il y en a un. Les compétences spécifiques de la suite sont portables : elles sont du code, elles peuvent être transmises. Les modèles d'engagement, les récits destinés aux clients, les goûts en matière de conception sont plus personnels mais peuvent être documentés, du moins en principe.

Ce qui ne peut pas être transféré facilement, c'est le jugement spécifique qui relie tout. L’intuition sur les engagements à prendre. L'examen du goût qui décide de ce qui est expédié. La voix particulière que les clients reconnaissent comme la mienne. Celles-ci sont véritablement les miennes d'une manière que même la meilleure documentation ne peut pas pleinement capturer, et tout successeur exécuterait une version de la pratique, pas la même pratique. C'est honnête, et c'est bien : un successeur devrait exécuter sa propre version, informé par la mienne mais sans y être lié.

L’élément spécifique de la réflexion successorale qui a changé ma pratique est le suivant : que serait-il vrai si j’étais heurté par un bus demain ? Les clients seraient-ils bloqués ? Les engagements en cours s’effondreraient-ils ? Les systèmes que j'ai construits pour mes clients continueraient-ils à fonctionner ou commenceraient-ils à échouer silencieusement au bout d'une semaine ? Toute réponse qui implique que la pratique ne puisse pas continuer en mon absence est une fragilité que je devrais réduire, même si l'événement spécifique qui la déclencherait semble improbable. Le facteur bus est un nombre réel, et le mien a été plus élevé que nécessaire à différents moments.

Les réductions spécifiques que j’ai faites sont pratiques. Chaque client dispose d'informations documentées sur le transfert : qui je suis, ce que nous faisons, où se trouvent les systèmes, qui contacter si je ne suis pas joignable. Chaque système client dispose d'un runbook : ce qu'il fait, comment il fonctionne, ce qui pourrait mal se passer, qui appeler si c'est le cas. Chaque engagement en cours comporte un plan de succession d'urgence approximatif : si je ne peux pas continuer, ce collègue spécifique pourrait le prendre en charge dans un court délai. Rien de tout cela n’est élaboré ; tout cela fait passer la situation d'un client de « dépend entièrement de ma présence continue » à « résiliente à des perturbations spécifiques ».

Le corollaire qu’il m’a fallu plus de temps pour accepter est que la préparation à la succession rend la pratique meilleure dans le présent, et pas seulement résiliente à mon absence. Les Runbooks qui pourraient aider un successeur m'aident également lorsque je reviens de deux semaines de vacances et que je ne me souviens plus de ce que fait un système. La documentation de transfert qui aiderait un client à trouver la continuité m'aide également à me souvenir de la forme de l'engagement six mois plus tard. Les disciplines qui réduisent la fragilité réduisent également les frictions, et la réduction de la fragilité est sans doute un effet secondaire heureux de la valeur de la réduction des frictions en soi.

Pensez à la succession sans la traiter comme morbide. Réduisez délibérément la fragilité. Écrivez les runbooks. Documentez les engagements. Non pas parce qu’un bus est imminent, mais parce que la pratique doit être robuste et que la discipline consistant à le rendre robuste l’améliore de manière rentable bien avant qu’une perturbation spécifique n’arrive.

La compétence de retraite

Chaque compétence de la suite a une fin. Certains se terminent rapidement – ​​conçus pour un engagement spécifique, qui ne sont plus nécessaires une fois l’engagement terminé. Certains se terminent lentement – ​​utilisés chaque semaine pendant un an, mensuellement l'année suivante, puis trimestriellement, jusqu'à ce que plus personne ne les gère. Ce chapitre porte sur les soins spécifiques que mérite une compétence retirée, car la manière dont vous mettez une compétence hors service vous apprend quelque chose sur la manière dont les compétences doivent être développées en premier lieu.

L’observation qui a déclenché cette réflexion était que certaines de mes compétences les plus anciennes – celles que j’avais acquises au début de ma pratique – avaient accumulé des erreurs dont je ne me souvenais plus de la raison. Une bizarrerie spécifique dans le format de sortie, une dépendance spécifique qui existait pour une raison perdue dans le temps, un comportement spécifique qui était autrefois correct et qui est désormais résiduel. Lorsque j'ai finalement décidé de retirer cette compétence, j'ai découvert que je ne pouvais pas expliquer complètement pourquoi elle fonctionnait ainsi, ce qui signifiait que je ne pouvais pas reconstruire en toute confiance la même fonctionnalité si jamais j'en avais besoin. La retraite a rendu visible l’obscurité accumulée.

L'acte spécifique de retraite qui m'a surpris était l'intérêt de rédiger une véritable note de retraite. Pas l'indicateur de dépréciation du chapitre 48 - un document plus long qui répondait "à quoi faisait cette compétence, pourquoi existait-elle, quelles étaient ses aspérités et que devrait-on faire si la fonctionnalité était à nouveau nécessaire". Écrire cette note m'a obligé à exprimer ce que je pensais savoir, et l'articuler a révélé à quel point ce que je savais était en réalité caché plus tôt et n'était plus valable. La note de retraite est un document qui n'est bien rédigé que parce qu'il est rédigé dans le cadre de la finalité de la retraite ; le même document rédigé en cours de service aurait sauté les parties importantes.

Il y a une leçon de conception en dessous : les compétences qui accumulent des éléments opaques sont des compétences que les lecteurs, six mois plus tard, ne peuvent pas comprendre. La note de retraite ne résout pas ce problème de manière rétroactive, mais la discipline de rédaction me permet d'acquérir des compétences ultérieures avec moins de choses à expliquer. Si je sais qu'une note de retraite arrivera éventuellement, je fais plus attention aux choix précis lors de la construction, car je sais que je devrai les justifier. La documentation anticipée est une fonction forçante pour une conception cohérente.

L'autre enseignement est que le retrait d'une compétence est souvent un moment d'apprentissage tout autant que sa construction. Ce que j'ai compris d'une classe de problèmes en développant la compétence était incomplet ; ce que j'ai compris après deux ans d'exercice de la compétence est différent, et souvent la conversation sur la retraite est le point de rencontre de ces deux versions de ma compréhension. La note de retraite est l'artefact de cette réunion - un document produit par le plus âgé, le plus sage, qui examine les choix du plus jeune, le moins informé, et les réconcilie.

Il y a un goût spécifique qui mérite d'être mentionné, qui n'est pas d'avoir honte des compétences que je retire. Certaines ont été construites à la hâte. Certains ont été construits sur la base d’hypothèses qui se sont révélées fausses. Certains ont tout simplement dépassé leur objectif. Aucun de ces éléments n’est un échec ; ils sont l'arc honnête d'une pratique qui a changé au fil des années. Une suite qui ne retire jamais rien est une suite qui fait comme si le monde n’avait pas bougé ; une suite qui se retire délibérément est une suite qui reconnaît le mouvement et s'adapte.

Rédigez la note de retraite. Apprenez-en. Laissez la discipline d’une retraite anticipée façonner la façon dont vous développez de nouvelles compétences. La fin d'une compétence est un événement de premier ordre dans la vie de la suite, pas une note de bas de page – et les documents produits à la fin sont souvent ceux qui informent sur la suite.

L'audit d'une année sur l'autre

Une fois par an, délibérément, je m'assois et audite ma pratique – non pas la télémétrie hebdomadaire, mais un long regard sur la façon dont la forme de mon travail a changé au cours des douze mois précédents. Quels types d’engagements ai-je pris ? Quels types de compétences ont été les plus utilisés ? Quel était le rapport entre les nouveaux travaux et l'entretien ? Dans quoi me suis-je amélioré et qu’est-ce qui est resté le même ? L'audit d'une année à l'autre est la propre rétrospective du cabinet, et c'est la réflexion disciplinée qui façonne l'année suivante.

La raison pour laquelle il faut procéder ainsi chaque année – et non mensuellement, ni trimestriellement – ​​est que des horizons plus courts masquent la dérive. De mois en mois, la pratique semble stable. D'un trimestre à l'autre, les changements sont encore faibles. Au fil d'un an, la dérive s'accumule pour devenir quelque chose de visible : de nouvelles catégories d'engagement sont apparues, les anciennes ont disparu, mon éventail de compétences s'est tranquillement remodelé, la liste des clients s'est à moitié renouvelée. Rien de tout cela n’était perceptible à aucun moment ; tout cela est perceptible dans son ensemble, et c’est cet ensemble que capture la vue d’une année sur l’autre.

Les questions spécifiques que je pose sont les suivantes. Quelle fraction de mes heures a été consacrée à quel pilier de l’ensemble de compétences ? Les piliers dans lesquels j’ai investi sont-ils ceux qui ont produit de la valeur ? Quel était le rapport entre les heures de nouveau travail et les heures de maintenance, et ce rapport est-il durable ? Quelles compétences ont été utilisées le plus souvent et étaient-elles celles que j’attendais ? Quels clients représentaient quelle fraction des revenus, et comment cette concentration a-t-elle changé ? Quel était le rapport entre mes heures d'activité et la contribution de la machine, et la capitalisation a-t-elle augmenté ?

Les réponses à ces questions me surprennent souvent. Je m'attends à avoir passé du temps sur X et découvre que j'ai réellement passé du temps sur Y. Je m'attends à ce qu'une relation client se soit approfondie et trouve qu'elle plafonne. Je m'attends à ce qu'une nouvelle compétence ait fait son chemin et je la trouve languie. C'est dans l'écart entre les attentes et la réalité que se trouvent les informations utiles, car les attentes sont le modèle que j'ai porté toute l'année et la réalité est ce qui s'est réellement passé. Corriger le modèle par rapport à la réalité, c'est à cela que sert l'audit.

Le résultat de l’audit est une courte réflexion écrite – une page, pas plus – capturant ce qui m’a surpris et ce sur quoi l’année suivante devrait mettre l’accent. Il ne s'agit pas d'un plan stratégique ; pas une feuille de route ; un ensemble d'observations sur ce qui fonctionne réellement et ce qui ne fonctionne pas. La stratégie vient plus tard, éclairée par la réflexion ; le reflet lui-même est la matière première. Sauter la réflexion et passer directement à la stratégie est la façon dont les plans stratégiques finissent par être déconnectés de la réalité qu'ils sont censés guider.

Il y a un avantage spécifique que j'ai mis quelques années à remarquer, à savoir que l'audit annuel construit une sorte de mémoire institutionnelle au fil des années. La lecture de la réflexion de l’année précédente parallèlement aux observations de l’année en cours montre un mouvement – ​​non seulement là où j’en suis maintenant, mais d’où je viens. C'est l'histoire de la pratique, racontée sous forme de brefs instantanés annuels, et c'est un élément de connaissance qu'aucune année seule ne pourrait produire. L'effet composé est que la réflexion de la cinquième année est beaucoup plus riche que celle de la première, car c'est une réflexion éclairée par quatre réflexions précédentes.

Faites l’audit annuel. Posez les questions spécifiques. Écrivez la courte réflexion. Lisez celui de l’année précédente lorsque vous écrivez celui de cette année. Des pratiques qui ne reflètent pas une dérive sans s'en apercevoir ; les pratiques qui reflètent orientent leur dérive, ce qui est la différence entre une carrière qui va quelque part volontairement et une carrière qui va là où l'inertie la mène.

L'entretien de sortie avec votre propre système

Vers la fin de la rédaction de ce livre, j’ai fait un exercice spécifique que je souhaite décrire, car il s’est avéré plus utile que ce à quoi je m’attendais. J'imaginais que je quittais mon propre cabinet – étant interviewé, en sortant, par la personne qui le reprenait. Que leur dirais-je ? Que savais-je du fonctionnement du système qui n’était écrit nulle part ? Qu’auraient-ils besoin d’entendre de moi, en personne, avant de pouvoir gérer cela comme il se doit ?

L'exercice m'a semblé délicat au début, car je ne quittais rien et le successeur imaginaire était hypothétique. Mais le cadrage a fonctionné. Cela m'a obligé à articuler des choses que j'avais en tête comme des connaissances tacites : les règles non écrites spécifiques qui maintiennent l'honnêteté de la pratique, les bizarreries particulières de chaque relation client, les éléments de jugement qui ont émergé au fil des années et qui n'avaient été capturés dans aucun document. Une fois articulés, la plupart d’entre eux valaient la peine d’être écrits correctement, non pas parce qu’un successeur était imminent mais parce que les articuler les rendait plus portables, même pour moi.

Les choses spécifiques que je me suis retrouvé à dire au successeur imaginaire se sont avérées être une taxonomie qui mérite d'être nommée. Les règles d'engagement non écrites : quels clients reçoivent quelle qualité d'attention, quelles demandes sont ralenties, lesquelles sont accélérées. Les décisions de goût spécifiques qui résident dans le système de conception : pourquoi la couleur d'accent est celle-ci, pourquoi les polices sont celles-ci, pourquoi les diagrammes ressemblent à ce à quoi ils ressemblent. Les relations entre les compétences qui ne sont pas documentées dans les manifestes – quel résultat de compétence alimente lequel, pourquoi certaines compositions fonctionnent et d'autres non. Les idiomes spécifiques au client – ​​les expressions qui signifient quelque chose de spécifique à un client particulier qu’un œil neuf passerait sous silence.

Chacun d’eux s’est avéré avoir une valeur au-delà de la succession imaginaire. Écrire les règles non écrites signifiait que je pouvais les revoir lorsque la pratique se développait ou que le contexte changeait ; ils sont devenus actualisables plutôt que fossilisés. Documenter les décisions gustatives signifiait que je pouvais les revoir sans les rediriger à chaque fois ; le goût est devenu reproductible. L'écriture des compositions signifiait que les compétences futures pourraient être construites en gardant le modèle à l'esprit ; la composition est devenue un principe de conception plutôt qu'un accident.

L'exercice s'est cristallisé sur une observation plus large, à savoir que les connaissances tacites coûtent cher à garder en tête, même pour soi-même. Ce qui semble être une intuition sans effort est en réalité une charge mentale qui consomme une attention que vous préféreriez consacrer ailleurs. L'externalisation des connaissances dans des documents vous permet de vous décharger de la charge, non pas en rendant les connaissances moins vôtres, mais en n'ayant pas à les garder activement à l'esprit. Le cabinet fonctionne mieux lorsque son propre opérateur ne constitue pas un goulot d'étranglement pour mémoriser son fonctionnement.

L'exercice a également révélé des lacunes. Des endroits où le successeur imaginaire aurait des questions auxquelles je ne pourrais pas répondre. Des endroits où j'avais improvisé d'une manière que je n'avais pas remarquée. Des endroits où la pratique fonctionnait malgré mes connaissances, pas grâce à elles. Chacun d’entre eux méritait d’être étudié : l’improvisation pouvait être une force cachée ou une faiblesse cachée, et dans tous les cas, la nommer permettait d’agir.

Faites l’exercice, même sans successeur à qui passer la main. Imaginez-en un. Interviewez-vous comme si vous partiez. Le document que vous produisez ne leur est pas destiné ; c'est pour vous, et sa valeur réside dans l'articulation elle-même, et non dans le transfert de responsabilité qu'elle pourrait un jour informer. Les pratiques qui peuvent s'articuler sont des pratiques qui peuvent s'améliorer ; des pratiques qui ne peuvent pas rester dépendantes de l'humain spécifique qui les dirige, ce qui est la fragilité avec laquelle nous avons commencé cette partie et la terminons maintenant en considérant délibérément.

Ce qui vient ensuite

Cent chapitres, et le livre se termine sur la question que tout lecteur est en droit de se poser : quelle est la suite ? Pas pour l’industrie de l’IA, dont je refuse de prédire l’avenir avec précision ; mais pour le praticien qui a lu jusqu'ici et qui décide quoi faire à ce sujet. C'est le chapitre que je voudrais, si j'étais le lecteur – les conseils honnêtes et non couverts de l'écrivain sur par où commencer.

La première chose qui vient ensuite, pour la plupart des lecteurs, n’est pas de construire un nouveau système. C'est passer une semaine à faire un audit honnête du travail que vous faites déjà. À quoi consacrez-vous vos heures actives ? Quelles parties de ce travail ne concernent que vous ? Quelles parties sont délégables et à quoi ? Quel est votre ratio actuel de débit actif/passif, et où de petits changements le déplaceraient-ils ? Répondez à ces questions avant de construire quelque chose de nouveau ; les réponses redirigent généralement ce que vous auriez construit.

La deuxième chose qui vient ensuite est de choisir une seule discipline dans ce livre et de l'adopter délibérément pendant un mois. Pas tous ; un. Choisissez celui dont l’absence semble faire le plus mal dans votre configuration actuelle. Si vous n'avez pas de grand livre, ajoutez un grand livre pour un mois. Si vous disposez d'une télémétrie sans coût, ajoutez une télémétrie avec coût. Si vos maquettes sont soignées, badgez-les. Quel que soit celui que vous choisissez, passez un mois à développer cette habitude avant d’en ajouter une autre. Essayer de tout adopter en même temps produit un désordre ; l’adoption séquentielle produit une pratique durable.

La troisième chose qui vient ensuite est d’être patient concernant la composition. Les disciplines de ce livre ne portent pas leurs fruits en quelques semaines. Ils portent leurs fruits au fil des années, et il y a de longues périodes pendant lesquelles les pratiques individuelles semblent être des frais généraux et la composition n'a pas encore fait effet. Faites-les quand même et donnez-leur le temps dont ils ont besoin. Les praticiens qui ont abandonné ces disciplines parce que « le gain individuel n’en valait pas la peine » sont ceux qui n’ont jamais atteint la zone de composition, et le gain ne réside pas dans une seule pratique – il est dans l’intersection de beaucoup d’entre elles, maintenue suffisamment longtemps pour que l’intersection devienne visible.

La quatrième chose qui vient ensuite est d'être honnête sur ce que vous ne savez pas. Ce livre représente les réponses d'une personne, développées à partir de la pratique d'une personne, avec ses angles morts. Ce que j'ai écrit peut ne pas correspondre à votre travail, à vos clients, à votre tempérament. Prenez les détails sans réfléchir ; prendre les positions sous-jacentes plus au sérieux ; prenez les modèles réels et traduisez-les par rapport à votre propre réalité. Le lecteur qui applique ce livre textuellement obtiendra de moins bons résultats que le lecteur qui en prend la forme et retravaille les détails en fonction de son propre contexte.

La cinquième chose qui vient ensuite – et la dernière chose sur laquelle je veux vous laisser – est un retour à la revendication du chapitre 1, que tout le livre a essayé de gagner. L'ingénierie de l'IA, bien faite, consiste moins à écrire de plus en plus sur la présence uniquement là où votre présence est la contrainte. Tout dans ces pages est un instrument de cette position. Le quart de nuit, l'ensemble des compétences, la discipline du client, le grand livre des coûts, la carte de vérification — tout cela existe pour protéger les vingt heures, pour concentrer l'attention humaine là où elle compte, pour déléguer le travail mécanique à une machine qui peut réellement le gérer. Si vous retenez une chose de ce livre, adoptez cette position et laissez les pratiques spécifiques être facultatives.

La pratique continuera d’évoluer. Les outils continueront de changer. Les chapitres spécifiques ici dateront de manière inégale. Ce que j’espère perdure, c’est le schéma sous-jacent : une attention limitée, appliquée aux parties du travail qui la récompensent, déléguant tout le reste à un système qui se gère lui-même. Le système spécifique que j'ai décrit est un exemple concret ; le modèle se généralise plus loin que les détails. Allez en construire votre propre version, et si vous vous retrouvez dans une pièce quelque part dans des années à raconter des histoires sur les disciplines qui l'ont fait fonctionner, certaines de ces histoires seront les vôtres, et d'autres feront écho aux miennes, et les deux appartiendront à la même conversation. C'est ce qui vient ensuite : votre version, informée mais non contrainte par celle-ci, effectuant un travail que vous seul pouvez faire, dans les vingt heures dont vous disposez réellement.