Je ne sais pas écrire
une ligne de code

Il faut le dire avant tout le reste, parce que c'est la seule chose qui donne du poids à ce livre : je ne suis pas développeur. Je n'ai ni diplôme ni carrière dans l'informatique. Je ne sais pas écrire une ligne de code.

Je suis diplômé en Management de Terminaux Portuaire auprès de la Lloyds Maritime Academy de Londres en Angleterre et douze ans de métier dans les opérations, la logistique et les terminaux portuaires en Afrique de l'Ouest. Ce que je sais faire, c'est monter une opération qui n'existe pas encore, avec une équipe qui ne la connaît pas encore, dans un délai qui ne laisse pas de marge.

Et depuis l'université, j'ai développé une passion pour l'ordinateur, grâce notamment à AIESEC et au Campus Numérique Francophone de l'UL (là où j'ai découvert les logiciels libres et le système d'exploitation Ubuntu/Linux).
Pas une compétence : une passion. La distinction compte, parce qu'elle décrit exactement la position de la plupart des gens qui liront ces pages : curieux de la machine, sans jamais avoir eu le temps ni la raison d'en apprendre le langage.

Ce livre est donc écrit depuis l'autre côté du mur. Pas par quelqu'un qui vulgarise ce qu'il maîtrise depuis toujours, mais par quelqu'un qui a appris récemment, en pratiquant, et qui se souvient encore précisément de ce qui était incompréhensible la veille.

Je n'ai pas appris à coder. J'ai appris à tenir la bride.

Ce que douze ans
d'opérations m'ont appris

On m'a confié plusieurs fois une chose qui n'existait pas.

En janvier 2026, un port sec à ouvrir près de Freetown en vingt-cinq jours : à mon arrivée, notre partenaire dégageait encore le terrain. En 2022, une opération d'import, stockage et exportation du coton à Adétikopé : la plateforme n'en avait jamais manutentionné, moi non plus, et le seul document qu'on m'a remis était la spécification d'empilage de l'assureur. Avant cela, j'ai eu à monter les opérations du site de dépotage des conteneurs ainsi que les opérations des entrepôts, après avoir construit la fonction Process Excellence sur un terminal à conteneurs de grande envergure à Lomé, au Togo.

À chaque fois, la même méthode : écouter avant de décider, définir le périmètre avant d'agir, verrouiller les règles non négociables avant la première opération, puis corriger par cycles.

En découvrant le harnais de pilotage de l'IA, je n'ai donc pas découvert une idée nouvelle : j'ai reconnu la mienne, appliquée à un autre métier. Un harnais logiciel est une procédure d'exploitation, avec son ordre des étapes, ses règles verrouillées d'avance et ses points de contrôle. C'est pour cela que j'ai pu l'étendre.

Novembre 2022

En novembre 2022, l'intelligence artificielle conversationnelle est mise à la disposition du grand public. J'ai été captivé immédiatement, et je ne me suis plus arrêté depuis : en autodidacte, et surtout en pratiquant, la seule manière d'apprendre un outil dont la documentation vieillit plus vite qu'on ne la lit.

La première fois que j'ai utilisé Claude, j'ai trouvé autre chose. Étant Manager, ce qui m'intéressait n'était pas la performance technique : c'était la capacité à raisonner sur un problème mal posé, à structurer ce qui arrive en désordre, à me contredire quand j'avais tort. Un Manager passe ses journées là-dedans. J'ai donc approfondi cet outil-là plutôt qu'un autre, et je n'ai pas cessé depuis.

Claude m'offrait la possibilité d'approfondir certains sujets, de faire du brainstorming et surtout de produire des livrables en word ou Excel de qualité professionnel. Mais quelque chose manquait, et je ne savais pas le nommer. Pour aller plus loin, surtout avec le code, il devenait évident que je n'avais pas les compétences qu'il fallait.  J'ai essayé de produire une application métier (dans le domaine de la logistique) avec Claude Code. Cela m'a consumé beaucoup de temps et d'énergie sans que l'application ne prenne réellement forme. Mes abonnements à Claude Pro puis Max, n'étaient donc pas rentabilisés comme je le souhaitais. 

Ce n'était pas un problème d'intelligence de la machine. C'était un problème d'ordre et de méthode, et c'est exactement mon métier, sauf que je ne l'avais pas encore vu.

Je savais ce que je voulais construire. Mais je n'avais pas l'outil qui me permettait de faire travailler la machine dans l'ordre qu'il faut.

Juillet 2026 :
le mot « harnais »

Début juillet 2026, je tombe sur une vidéo YouTube. Un jeune développeur français, Flavien Chervet, y est interviewé, et il emploie un mot que je n'avais pas entendu dans ce sens : le harnais.

Son constat était celui que je n'arrivais pas à formuler : le harnais est ce qui manquait aux non-techniciens pour obtenir de véritables résultats de l'IA. Pas un modèle plus puissant, pas une meilleure formulation des demandes, mais une couche au-dessus, qui sait quoi faire et dans quel ordre. Il expliquait en avoir mis un en place, et que ses étudiants non-techniciens menaient avec lui des projets de bout en bout.

Il annonçait qu'il l'ouvrirait plus tard en open source (logiciel dont le code est mis à disposition du public), et j'ai attendu cette ouverture.

Quand il l'a ouvert, je l'ai pris, je l'ai étudié, et j'ai commencé à l'adapter aux réalités de l'Afrique de l'Ouest en général et de la zone UEMOA en particulier.

Ce que nous y
avons ajouté

Un harnais conçu ailleurs suppose un marché qui n'est pas le nôtre, et la première divergence est le paiement.

Là où le harnais d'origine parlait d'intégrer Stripe, j'ai ajouté FedaPay, qui encaisse par mobile money. Ce n'est pas une préférence technique : c'est ainsi que nos clients paient. Un produit ouest-africain qui n'accepte que la carte refuse la majorité de son marché.

Puis d'autres commandes, chacune née d'un manque rencontré (la liste ci-dessous n'est pas exhaustive de nos commandes propres mais elle est à titre indicatif) :

Et d'autres encore, plus une réécriture continue de ce qui existait. Aujourd'hui, Dicko Soka est à environ 60 % notre travail propre.

Dicko Industries

Trois produits, une même conviction : l'outil doit porter le savoir-faire, pas seulement l'exécution. Ce qu'un professionnel apprend à ses dépens doit devenir une règle que le produit applique de lui-même, qu'il s'agisse d'un harnais logiciel, d'une déclaration en douane ou d'une clé à choc.

Ce livre ne traite que du premier. Le deuxième en est né, et c'est la meilleure preuve que la méthode tient : un produit vendu, conçu sans développeur, par l'auteur de ces pages.

Ce livre,
et à qui il parle

Vous avez une idée. Peut-être une gêne quotidienne dans votre métier, peut-être un service que personne n'offre autour de vous. Ce qui vous manque n'est pas l'idée : c'est le chemin entre elle et un produit que des gens utilisent et paient.

Ce livre décrit ce chemin. Il ne vous apprend pas à programmer, et c'est délibéré : le harnais Dicko Soka existe précisément pour que vous n'ayez pas à le faire. Il vous apprend à quoi sert chaque étape, dans quel ordre, et pourquoi cet ordre-là.

Et si votre projet n'est pas numérique, ne refermez pas ce livre. La moitié du parcours ne produit pas une ligne de code. Un atelier, un commerce, une auto-école se conduisent par les mêmes étapes qu'une application, parce que ce que le harnais structure n'est pas la construction : c'est la réflexion. Le chapitre 3 est écrit pour vous.

Ce que ce livre n'est pas

Ce n'est pas un manuel qui vous dit où cliquer. Les écrans changent, les manuels avec captures vieillissent en quelques semaines, et un lecteur qui suit une capture périmée conclut que l'outil est cassé alors que c'est le livre qui l'est.

Ce livre est conceptuel. Il explique le raisonnement derrière chaque étape, celui qui reste vrai quand un bouton se déplace. Quand vous saurez POURQUOI on isole une base de données avant de tester, la commande exacte sera la partie facile, et l'outil vous la donnera lui-même, puisqu'il est fait pour ça.

Le chiffre qui explique la méthode de ce livre

Ce livre décrit la version 3.86.0 du harnais.

Ces nombres ne sont pas écrits à la main dans ce livre. Ils sont lus dans le harnais au moment où le livre est fabriqué, et c'est une leçon payée. Un livre imprimé avec un chiffre recopié serait faux avant même d'être téléchargé, et cette fois chez ses lecteurs, sans rattrapage possible.

Alors chaque fait de ce livre (la liste des étapes, leur ordre, les noms des commandes) est relu dans le produit à chaque fabrication. Si vous lisez un chiffre ici, il était vrai pour la version nommée en page de titre. Vérifiez toujours cette version, en page de titre et sur la dernière page du livre : c'est la date de péremption de ce livre.

Comment le lire

Les douze (12) chapitres suivent le parcours dans son ordre réel, de l'idée non validée jusqu'aux premiers clients. Vous pouvez les lire d'affilée, ou ouvrir directement celui de l'étape où vous êtes.

Une seule chose à retenir si vous ne retenez rien d'autre : quand vous ne savez pas quoi faire, le harnais répond à cette question lui-même. La commande /next regarde où vous en êtes et nomme l'étape suivante avec sa raison. C'est la seule commande qu'il faut mémoriser.

Enfin, si vous préférez ne pas commencer seul : la page Par où commencer, en fin d'ouvrage, dit comment nous joindre. Vous pouvez y aller tout de suite.

Le principe

Ce que vous décrivez, la machine le construit

Vous écrivez ce que vous voulez, en français, dans une conversation. La machine écrit le code, crée la base de données, met le site en ligne. Vous ne relisez pas le code : vous regardez le résultat et vous dites ce qui ne va pas.

C'est un renversement, et il mérite d'être nommé : la compétence rare n'est plus d'écrire le code, c'est de savoir ce qu'on veut. Décrire précisément un besoin, reconnaître un résultat correct, arbitrer entre deux options : c'est ce que vous apportez, et aucun outil ne le fait à votre place.

Pourquoi un harnais, et pas seulement un assistant

Un assistant seul répond à ce qu'on lui demande. Il le fait bien, et c'est exactement le problème : si vous ne savez pas qu'il faut isoler une base de données avant de tester, il ne le fera pas, et rien ne vous dira que vous venez de tester sur les données réelles de vos clients.

Le harnais est la couche qui sait ce qu'il faut faire même quand vous ne le demandez pas. Il connaît l'ordre des étapes, les pièges du marché où vous vendez, les vérifications obligatoires avant une mise en ligne. Ses 105 commandes ne sont pas 105 fonctionnalités : ce sont 105 décisions déjà prises, testées, et qui n'ont plus à être reprises à chaque projet.

105 commandes, ce ne sont pas 105 fonctionnalités : ce sont 105 décisions déjà prises.

Trois règles qu'il ne négocie pas

Ces règles ne sont pas des préférences, ce sont des lignes rouges. Aucun réglage d'autonomie ne les lève.

Ce que ça change pour vous

Vous ne devenez pas développeur. Vous devenez quelqu'un qui livre. La différence entre une idée et un produit n'est plus une compétence technique à acquérir pendant deux ans : c'est un parcours à suivre, et le chapitre suivant le décrit en entier.

Le parcours
en entier

C'est le chapitre le plus important du livre. Tous les autres décrivent une étape ; celui-ci montre pourquoi elles s'enchaînent dans cet ordre.

La carte

Le parcours n'est pas une file unique. Deux pistes avancent en parallèle : la piste produit construit la chose, la piste marché trouve les gens qui la paieront. Les étapes communes servent les deux.

Deux pistes, pas une file d'attente

Pourquoi cette séparation existe : une session consacrée au marketing à qui on répond « va construire un environnement de test » reçoit un conseil qui n'est pas faux, mais hors sujet, et une boussole hors sujet se fait ignorer, puis désinstaller. Le harnais regarde donc sur quelle piste vous travaillez avant de recommander quoi que ce soit.

Requis, optionnel, et pourquoi la distinction compte

Certaines étapes sont requises : sans elles, ce qui suit ne tient pas. D'autres sont optionnelles selon votre projet : un site vitrine sans comptes n'a pas besoin de tout ce qu'une application avec abonnements exige.

Le harnais ne vous bloque jamais sur une étape optionnelle. Il vous dit ce qu'elle apporterait, et vous décidez. Sur une étape requise, il insiste, et sur l'audit de sécurité avant mise en ligne, il refuse de passer outre.

Vous n'avez pas à mémoriser cette carte. Le harnais la lit pour vous.

La commande à retenir

Tapez /next : le harnais lit où vous en êtes, non pas ce que vous avez déclaré mais ce qui existe réellement sur votre disque et en ligne, puis nomme l'étape suivante et sa raison, en une ligne.

Si vous préférez qu'il enchaîne tout seul aussi loin qu'il le peut, /pilot fait le vol complet, s'arrête là où une décision humaine est nécessaire, et vous dit pourquoi il s'est arrêté.

Si votre projet
n'est pas numérique

Ce chapitre existe parce que les deux précédents ont pu vous laisser croire que ce livre parle de logiciel. Il parle de méthode. La différence décide de qui peut s'en servir.

La moitié du parcours ne produit pas une ligne de code

Reprenez la carte du chapitre précédent et regardez ce que chaque étape fabrique. Huit (8) des seize (16) étapes ne produisent aucun code : elles produisent des documents, des chiffres et des décisions.

Un commerce, un atelier, une exploitation agricole, un service de transport, une auto-école: tous passent par ces huit étapes. Aucun n'a besoin des huit autres.

Ce que le harnais apporte vraiment

Ce n'est pas la construction. C'est une discipline de réflexion qui refuse de vous laisser sauter les questions qui coûtent cher.

Un cahier ne vous demande pas vos sources. Un tableur ne vous contredit pas. Un ami à qui vous exposez votre idée vous encourage, parce qu'il vous aime bien. Le harnais fait l'inverse : il exige des sources datées, il nomme la personne exacte qui paiera, il vous demande à quel prix le marché achète aujourd'hui et si vous l'avez vérifié ou supposé. Puis il énonce un verdict que vous n'aviez pas envie d'entendre.

Ce qui est structuré n'est pas la construction. C'est la réflexion.

Un exemple, du début à la fin

Prenons un projet qui ne touche à aucun écran : une savonnerie artisanale à Lomé. Voici ce que le parcours donne.

Au bout de ce chemin : pas de site, pas d'application, pas une ligne de code. Un business documenté, chiffré et contesté avant la première dépense. C'est exactement ce que la plupart des projets ne font jamais, et c'est pourquoi la plupart des projets meurent de choses qu'on pouvait savoir d'avance.

Si un jour cette savonnerie veut vendre en ligne, les huit autres étapes l'attendent. Mais elles attendent : elles ne conditionnent rien.

Ce que le harnais ne fera pas

Il ne visite pas votre local. Il ne goûte pas votre produit. Il ne négocie pas avec votre fournisseur et ne remplace pas une matinée passée au marché à regarder ce que les gens achètent vraiment. Il structure votre réflexion ; le terrain reste le vôtre, et il reste irremplaçable.

Une limite honnête, aussi : sur un marché très local, ses sources sont plus minces que sur un marché documenté. Quand la preuve est mince, il le dit au lieu de combler le trou, et c'est à vous d'aller chercher le reste.

Avant de construire

L'erreur la plus chère n'est pas un bug. C'est six mois passés à construire quelque chose dont personne ne veut. Ce chapitre décrit les étapes qui coûtent quelques heures et en économisent des centaines.

Chercher la douleur avant d'avoir l'idée

Si vous n'avez pas encore d'idée, c'est une bonne position, meilleure que d'en avoir une à laquelle vous tenez déjà.

/pain-point-finder part d'un secteur, d'un pays ou d'un métier, et cherche des problèmes documentés : ce que les gens écrivent eux-mêmes sur les forums et dans les avis, la littérature académique, les rapports institutionnels, et ce que d'autres ont déjà tenté, y compris leurs échecs, qui sont la source la plus instructive.

Chaque douleur remontée porte au moins deux sources indépendantes, citées et datées. Jamais une référence inventée : quand la preuve est mince, le rapport le dit au lieu de combler le trou. Une opportunité fondée sur une source imaginaire est pire qu'aucune opportunité, parce qu'elle a l'air sérieuse.

Passer l'idée au feu

/ideate est un partenaire critique, pas un supporter. Il conteste : le problème est-il réel ou supposé ? Qui exactement souffre ? Que font ces gens aujourd'hui, et pourquoi votre solution serait meilleure que leur système D actuel ? Quel est le modèle économique défendable ? Qu'est-ce qui vous tuerait ?

Il ne valide jamais une idée par politesse. Un « non » argumenté est un succès de cette étape : il vous rend les mois que l'idée allait coûter. Le verdict est un go, un no-go ou un pivot, et il s'appuie sur ce qui a été trouvé, pas sur votre enthousiasme.

Un « non » argumenté est un succès de cette étape : il vous rend les mois que l'idée allait coûter.

Écrire ce qu'on construit

/spec transforme le go en cahier des charges : les fonctionnalités, les écrans, ce qui est dans la première version et surtout ce qui n'y est pas.

La liste des exclusions est la plus utile du document. Une première version qui essaie de tout faire ne sort jamais, et le harnais vous aidera à défendre ce périmètre quand la tentation d'ajouter reviendra, et elle reviendra.

Ce document n'est pas de la paperasse : /bootstrap le lit et construit à partir de lui. Ce que vous écrivez ici devient le projet.

Le modèle économique, si l'argent est en jeu

/bmc déroule les neuf blocs du Business Model Canvas (un outil visuel qui permet de présenter une idée de business sur une seule page) dans leur ordre de dépendance, en partant de ce que l'idéation a validé. Il conteste les blocs faibles (une source de revenu sans segment de clientèle en face, une activité clé que personne ne porte) et esquisse un compte de résultat mensuel dans votre monnaie.

Ce qui tourne
sous le capot

Vous n'avez pas besoin de savoir programmer. Mais savoir quelles pièces composent votre produit vous sert trois fois : pour comprendre ce que vous payez, pour parler à un prestataire si un jour vous en prenez un, et pour ne pas être prisonnier d'un outil.

Ce chapitre est le seul du livre à nommer des technologies. Vous pouvez le sauter en première lecture.

Les pièces, et à quoi chacune sert

Ce que ça coûte pour démarrer

Presque tout ce qui précède a un palier gratuit, et le harnais est conçu pour y rester le plus longtemps possible. Les commandes /quotas et /billing vous montrent où vous en êtes sur chaque service, et vous alertent avant la falaise plutôt qu'après.

La première dépense n'est pas dans cette liste. Pour exécuter ces commandes, il faut un accès à l'assistant qui les exécute, et deux portes existent. Antigravity, l'hôte de Google : son palier gratuit s'utilise tel quel, sans abonnement, et il comporte une limite hebdomadaire que Google ne publie pas. Claude Code, l'hôte d'Anthropic : par abonnement, par compte facturé à l'usage (souvent la voie la moins chère pour commencer), ou via un fournisseur tiers. Le harnais tourne sur les deux, mêmes commandes, mêmes projets. Si la dépense compte, commencez par la porte gratuite.

Le mot qui compte : vous n'êtes pas enfermé

Tout ce que le harnais construit vous appartient. Le code est dans votre dépôt, la base est sur votre compte, le nom de domaine est à votre nom. Si vous décidez un jour de continuer sans le harnais, ou avec quelqu'un d'autre, rien ne vous retient : c'est du code standard que n'importe quel développeur du métier sait reprendre.

Le démarrage
du projet

/bootstrap est la commande qui transforme un dossier vide en projet en ligne. En une séance, vous passez d'une idée écrite à une adresse que vous pouvez ouvrir dans un navigateur et montrer à quelqu'un.

Ce qu'il vous demande, et pourquoi

Il pose peu de questions, et chacune décide de quelque chose qu'on ne peut pas deviner.

Si la machine a déjà servi à publier pour une entreprise, elle vous la propose, et vous la confirmez à voix haute, même s'il n'y en a qu'une. Cette insistance a une raison : redemander huit champs coûte deux minutes, tandis que publier le numéro d'immatriculation d'un client sur le site d'un autre est une faute dans un document légal, et une faute invisible, car personne ne relit ses mentions légales après la mise en ligne.

Ce qu'il fait sans le demander

Ce dernier point est celui qu'on remarque seulement quand il manque : si vous vendez ce projet à un client, il est en règle le jour de la livraison.

À la fin

Vous avez une adresse. Elle affiche une page d'accueil sobre, elle est en ligne, elle est à vous. Ce n'est pas encore votre produit : c'est le socle sur lequel les chapitres suivants ajoutent ce qui le rend utile.

Le harnais vous annonce alors l'étape suivante et sa raison, et vous n'avez qu'à la suivre.

Ce que la question mobile décide

Une précision, parce qu'elle décide de votre architecture. Le harnais construit des sites et des applications web complets : 104 de ses 105 commandes y tournent. Du côté mobile, la vraie question n'est pas « mobile ou web » : c'est ce que vous vendez.

Les boutiques d'applications distinguent deux choses. Ce qui est livré dans le monde réel, une course, une livraison, un repas, une marchandise, une prestation, ne relève pas de leur système d'achat intégré : votre application encaisse librement, par T-Money, Flooz ou autre. C'est ainsi que Gozem vous fait payer une course. Ce qui est consommé dans l'application, un abonnement, des crédits, du contenu premium, doit au contraire passer par leur système d'achat intégré, lequel n'accepte pas le mobile money. Là, et là seulement, la porte est fermée : pour notre marché ce n'est pas une commission de 30 %, c'est un moyen de paiement qui n'existe pas chez eux.

D'où la solution que le harnais applique par défaut quand vous vendez du numérique : on encaisse sur le web, là où le mobile money passe sans obstacle, et l'application se contente de consommer un droit déjà payé. Vous n'avez rien à arbitrer, c'est le mode proposé d'office.

Et une limite qui est la nôtre, celle-là

Aujourd'hui, sur un projet mobile, le harnais crée l'application, son serveur en ligne et les comptes de vos utilisateurs : cette partie existe et a été éprouvée. Ce qu'il ne sait pas encore faire à votre place, c'est brancher la caisse. L'encaissement est écrit pour un site ou une application web, et personne ne l'a encore relié à un écran d'application mobile. Vous pouvez donc démarrer un projet mobile avec le harnais ; le paiement, lui, se câble encore à la main.

Les outils
du quotidien

Une fois le projet né, quelques commandes reviennent presque chaque séance. Les connaître change le rythme de travail.

Savoir où vous en êtes

Donner un visage au produit

Vérifier avant de montrer

Surveiller ce que ça coûte

Quand vous ne savez plus

Et /next, toujours. C'est la commande à retenir si vous n'en retenez qu'une.

Une dépense sans trace est une dépense qu'on refait par accident.

Ajouter
une capacité

Votre site existe. Il lui manque des comptes utilisateurs, des paiements, un formulaire de contact. Chaque capacité s'ajoute par une commande qui écrit le code, pose la configuration, et met à jour la documentation du projet.

Les grandes familles

Pour les comptes, /add-auth installe l'authentification. Par défaut il crée des comptes utilisateurs ET un administrateur, parce qu'un produit avec des utilisateurs et sans personne pour les administrer est un produit qu'on découvre incomplet des semaines plus tard, une fois l'application bien avancée.

Pour l'argent, /add-stripe couvre les cartes internationales et /add-fedapay le mobile money d'Afrique de l'Ouest. La bascule en mode réel, celle où de vrais euros ou francs circulent, exige toujours votre accord explicite.

Pour les données, /db-isolate sépare votre base de travail de la base réelle : c'est l'étape du chapitre suivant, et la sauter est la faute la plus coûteuse du parcours.

Pour l'automatique, la différence entre un enchaînement (workflow) et un agent n'est pas l'intelligence, c'est la boucle : un enchaînement fini se termine, un agent tourne.

Ce qu'elles font toutes, sans le dire

Chacune vérifie que ce dont elle dépend est déjà là, refuse proprement en le nommant sinon, écrit sa configuration aux bons endroits, met à jour la documentation du projet, et déclare ses nouveaux sous-traitants au registre de confidentialité quand elle en introduit.

Ce dernier point est celui qu'on oublierait toujours à la main : ajouter une carte interactive envoie l'adresse IP de chaque visiteur chez un tiers, et votre page de confidentialité doit le dire.

Mettre en ligne,
en trois temps

Voici le chapitre où l'on perd de l'argent quand on va trop vite.

Trois environnements, toujours

Pourquoi trois et pas deux

Parce que le premier test de paiement doit être fait par vous avec de l'argent factice, et non par votre premier client avec le sien.

Et parce qu'une base de test vous laisse essayer les cas laids (créer, supprimer, refaire) sans risquer les données de gens réels.

Un test sur la base de production n'est pas un test, c'est une manipulation en direct.

Ce que le harnais vérifie à votre place

Sur le palier de test comme en production, il ne se contente pas de lancer le déploiement : il vérifie que la construction a réussi, sur la bonne branche. Cette précision a une histoire : demander « le dernier déploiement de test » sur un projet à plusieurs branches vivantes répond sur le déploiement de quelqu'un d'autre, et ce verdict ressemblerait à un succès tout en ne prouvant rien.

Il vérifie aussi qu'une adresse de test n'est pas derrière un mur de connexion : une copie privée que vous seul pouvez ouvrir ne sert pas à faire tester quelqu'un.

La séquence, en clair

Jamais de raccourci vers l'étape 4. Vous pouvez configurer le harnais pour qu'il soit plus autonome sur les étapes 2 et 3 ; l'étape 4 reste la vôtre, sauf à l'avoir explicitement demandé autrement.

Et l'autonomie ne s'achète pas d'un simple réglage. Même au niveau le plus permissif, le harnais exige en plus une preuve de sécurité fraîche et une vérification de code sans avertissement. Déléguer davantage ne veut pas dire vérifier moins.

La dernière porte

/launch est la vérification d'avant-ouverture : l'audit de sécurité est-il passé, les valeurs d'exemple ont-elles été remplacées, les conditions commerciales des services que vous utilisez sont-elles réglées. Il bloque sur ce qui doit bloquer.

Et il ne se contente pas de trouver un audit réussi quelque part dans l'historique. Un audit passé sur du code que quarante enregistrements ont depuis remplacé ne prouve plus rien : la fraîcheur se juge sur l'empreinte du contenu vérifié, et non sur une date. Si ce n'est plus le même code, l'audit est refait.

Le reste, le nom de domaine et les emails à ce nom, se pose avant ou après, mais la vérification, elle, passe avant.

Trouver
des clients

Un produit en ligne que personne ne connaît ne rapporte rien. Cette moitié du parcours est celle qu'on saute le plus souvent, et c'est celle qui décide si le reste aura servi.

Le plan, avant les publications

/gtm construit le plan d'acquisition de votre produit, pas du marketing générique. Il lit ce que l'idéation a validé et le marché déclaré du projet, puis travaille quatre choses :

Puis le visage, puis les mots

L'ordre compte, et il a été appris à ses dépens : /gtm d'abord, /pitch ensuite, /brand-kit en dernier. Un kit visuel construit avant le plan produit des visuels pour des canaux que le plan écartera. C'est arrivé, et c'était payé à l'image.

/pitch écrit l'argumentaire : la page de vente, le message de prospection, la présentation courte. /brand-kit habille ensuite ce qui a été décidé.

Exécuter

/promote transforme le plan en matériel prêt à lancer : séquences de messages avec la discipline anti-spam intégrée, calendrier de contenu, briefs de campagne publicitaire avec ciblage et budget, plan de mesure.

Mesurer, et corriger

/metrics installe le suivi : combien de visiteurs, combien s'inscrivent, combien paient, et où ils abandonnent. Sans ces chiffres, améliorer un produit revient à deviner.

L'endroit où les gens abandonnent est presque toujours une surprise. C'est pour ça qu'on mesure au lieu de supposer.

Le meilleur moment pour savoir qui achètera est avant d'avoir fini de construire, car il est encore temps de changer ce qu'on construit.

Bien décrire
ce qu'on veut

C'est la compétence centrale de cette manière de travailler, et la seule que le harnais ne peut pas exercer à votre place.

Le principe : décrire le résultat, pas la méthode

La seconde n'est pas mauvaise parce qu'elle est technique, mais parce qu'elle impose une solution avant d'avoir décrit le besoin. Si le tableau n'était pas la bonne forme sur téléphone, vous venez d'interdire la bonne réponse.

Dites quoi et pour qui. Laissez le comment.

Les quatre questions qui rendent une demande exécutable

Avant de demander quelque chose, vérifiez que votre phrase répond à ceci :

Reconnaître un résultat, sans lire le code

Vous ne relisez pas le code. Vous vérifiez le comportement, et cela s'apprend vite : essayez le cas normal, puis essayez de casser. Champ vide, texte à la place d'un nombre, double clic sur le bouton d'achat. Regardez sur téléphone, pas seulement sur ordinateur, car la majorité de vos visiteurs y sera.

Et si quelque chose vous paraît étrange, dites-le, même sans savoir l'expliquer. « Cette page met du temps à s'afficher » est un rapport parfaitement utile.

Ce qu'il ne faut pas faire

Ne validez pas ce que vous n'avez pas regardé. Un « ça a l'air bon » sur un écran jamais ouvert est la manière la plus sûre de découvrir un défaut chez un client.

Ne demandez pas trois choses dans une phrase. Vous ne saurez pas laquelle a mal tourné.

Ne dites pas « comme d'habitude ». Chaque conversation repart d'un contexte propre ; ce qui a été décidé se réécrit ou se range dans le projet, et le harnais a justement un manifeste pour ça, qui retient une décision une fois pour toutes.

Travailler
avec la machine

Quelques habitudes qui séparent une séance productive d'une séance frustrante.

Une chose à la fois

Demandez une modification, regardez-la, validez-la. Puis la suivante.

Trois demandes empilées produisent un résultat où vous ne savez plus quoi a cassé quoi, et revenir en arrière devient une négociation. Le harnais enregistre le travail par petits paliers pour cette raison exacte : un palier validé est un point de retour.

Dire ce qui ne va pas, sans savoir pourquoi

Vous n'avez pas à diagnostiquer. « Le bouton ne fait rien quand je clique deux fois vite » est un excellent rapport, meilleur qu'une hypothèse sur la cause, qui enverrait chercher au mauvais endroit.

Les moments où on vous demande de choisir

Le harnais s'arrête à certains points et attend. Ce n'est pas de l'hésitation : ce sont les décisions qui vous appartiennent.

Et ces arrêts ne sont pas une intention écrite dans une consigne, que la machine pourrait interpréter largement un jour de zèle. Ils sont tenus par un registre de vingt-quatre portes que le harnais doit consulter avant d'agir : l'argent réel, les suppressions, les écritures en production, le passage d'un paiement en mode réel. Une règle qu'on peut contourner par une formulation habile n'est pas une règle.

Répondez à ces questions plutôt que de les contourner. Elles existent parce que quelqu'un a payé leur absence.

Quand la conversation devient longue

Une longue séance perd en précision : les décisions du début s'estompent. Le harnais le signale et propose une passation, un document qui résume l'état, les décisions prises et leurs raisons, ce qui reste à faire, plus un texte prêt à coller pour reprendre ailleurs. La commande /handover sert à cela. 

Acceptez quand c'est proposé. Une passation s'écrit pendant que le contexte est encore net, pas quand il ne l'est plus.

Ce que la machine ne fera pas à votre place

Elle ne sait pas si votre prix est le bon. Elle ne sait pas si vos clients préfèrent le mobile money à la carte. Elle ne sait pas si le nom que vous avez choisi sonne mal dans la langue de votre marché.

Elle construit vite et bien ce que vous décidez. La décision reste la partie humaine, et c'est celle qui fait la différence entre un produit qui marche et un produit qui existe.

Vous avez
la carte

Le reste est du travail, et le travail commence par une commande.

La différence entre les gens qui livrent et les autres n'est pas le talent technique. C'est d'avoir commencé, puis de ne pas s'être arrêté à la première étape ennuyeuse, qui est souvent l'audit de sécurité, ou le plan d'acquisition, c'est-à-dire précisément celles qui décident si le produit vivra.

Par où commencer

Ce livre décrit le chemin. Le parcourir seul est possible : le harnais est fait pour ça, et quand vous ne saurez plus quoi faire, /next vous dira l'étape suivante et pourquoi c'est celle-là.

Quatre portes, si vous préférez ne pas commencer seul.

Vous n'avez besoin d'aucune des quatre pour commencer. Vous avez la carte.