Comment nous travaillons · un projet, de bout en bout
Le prouver.
Le durcir.
Le porter.
Chaque projet suit le même chemin : prouvé vite, durci par une chaîne automatisée, puis porté toute sa vie. La séquence ne change pas, et c'est tout l'intérêt. Faites défiler pour la parcourir une fois.
Station 01 · La matière
L'administratif est la matière.
Les formulaires, les validations, les rapprochements, les passations de onze jours, le tableur que quelqu'un refait chaque mois. Dans une quinzaine de pays, ce travail est fait par des personnes recrutées pour autre chose.
C'est sans gloire, c'est énorme, et c'est presque entièrement automatisable. Voilà la matière dans laquelle nous travaillons.
Station 02 · Moitié 1 — PoC Services
Le prouver, vite.
Des ingénieurs à l'aise avec le métier s'installent dans une entreprise, comprennent comment elle fonctionne réellement, et construisent quelque chose qui marche avec des agents d'IA. Ils prouvent — ou réfutent — la valeur, mènent le projet au MVP, et le transmettent.
- Profil
- Forward Deployed Engineers
- Horloge
- Des jours pour quelque chose de simple, des semaines pour quelque chose de complexe
- Se termine quand
- La valeur est prouvée et le dossier de transmission est livré
Station 03 · La chaîne d'industrialisation
Chaque projet y passe.
Sans exception.
Un agent planifie, puis un flux automatisé ajoute ce qu'un prototype n'a pas : la montée en charge multi-utilisateurs, l'authentification, l'exécution asynchrone, les API, les webhooks et les tests. Les humains n'interviennent que lorsque l'agent les demande.
Un quasi-MVP dont la valeur est prouvée
Un système déployé, testé, sécurisé et multi-utilisateurs
Station 04 · Moitié 2 — Le Tech Lab
Et ensuite quelqu'un le porte.
Un Product Owner et un développeur reprennent le produit durci et le portent toute sa vie : recueillir les besoins du métier, continuer à construire, le maintenir, l'exploiter.
- Profil
- Product Owner · développeurs · DevOps
- Horloge
- En continu, toute la vie du produit
- Se termine quand
- Jamais — c'est l'équipe qui le garde en vie
Station 05 · La boucle se referme
Ce qu'apprend son exploitation
devient la prochaine entrée.
Vous avez fait un tour complet. C'est toute la société : un chemin agentique et reproductible de l'idée au produit en service, et retour.
Tout le parcours, en détail →Une équipe de PoC sans équipe produit est un cimetière de prototypes — des démos qui impressionnent, rien en production. Une équipe produit sans équipe de PoC construit ce que personne n'a demandé.
La plupart des programmes d'automatisation ont exactement l'une des deux moitiés, et blâment les personnes plutôt que la structure. Celui-ci est bâti comme une boucle pour que cela ne puisse pas arriver.
Pourquoi nous construisons plus vite
Chaque implémentation commence par un agent qui la planifie, travaille l'architecture à fond et relit ce qui en sort. Les ingénieurs dirigent ce travail et décident de ce qui part en production. Le gain n'est pas qu'il s'écrit plus de code — c'est que les parties lentes de la construction, la lecture, la vérification et le second avis honnête, cessent d'être ce que tout le reste attend.
La relecture est faite par quelque chose qui n'a pas écrit le code et qui n'a aucun souvenir d'avoir voulu quoi que ce soit avec. Un auteur qui relit son propre travail, humain ou non, confirme de façon fiable ce qu'il voulait faire plutôt que ce qu'il a réellement fait.
Les agents ne rentrent pas chez eux non plus. Une panne à trois heures du matin est vue au moment où elle arrive, remontée jusqu'à ce qui a réellement cassé, et accompagnée d'un correctif proposé qui attend l'arrivée de l'équipe. Personne n'est réveillé, et rien ne reste intact jusqu'au lundi.
Les personnes sont meilleures pour le jugement, pour le contexte, pour savoir si une chose mérite d'exister. Elles ne sont pas meilleures pour être disponibles en continu, et le leur demander est la façon dont les équipes s'usent. Nous utilisons donc les personnes pour le premier et les agents pour le second.
Rien de ce que produit un agent n'atteint la production sans qu'une personne l'approuve. C'est cette contrainte qui rend tout le reste dicible sans risque.
Tout le parcours
La traversée ci-dessus en est un tour complet. Le voici étape par étape, ce que vous voulez si vous décidez de nous confier quelque chose.
Moitié 1 · PoC Services — le prouver
- 0 Réception
Le problème, le responsable, le critère de réussite, ce que cela coûte aujourd'hui et quelles données cela touche — puis noté dans un palier de taille par quelqu'un qui ne répond pas du résultat. C'est cette indépendance qui rend la promesse honnête.
- 1 Comprendre le processus
Comment le travail se déroule réellement aujourd'hui, observé plutôt que décrit. L'essentiel de la valeur se trouve ici, pas dans la construction.
- 2 Vérifier ce qui existe déjà
Réutiliser avant de réinventer, appliqué avant qu'une ligne ne soit écrite.
- 3 Écrire l'architecture fonctionnelle
La rigueur de spécification avant la construction. Ce que cela fait, pour qui, et ce que « terminé » veut dire.
- 4 Construction agentique
Les agents construisent l'essentiel. L'ingénieur dirige, relit et décide.
- 5 La boucle avec les parties prenantes
Trois prototypes de plus en plus réels, montrés à ceux qui font le travail tant qu'il est encore peu coûteux de se tromper. Chaque présentation commence par dire ce que ce n'est pas encore.
- 6 Quasi-MVP et dossier de transmission
Valeur prouvée ou réfutée, plus tout ce dont l'équipe suivante a besoin. Quasi-MVP veut dire utilisable, pas production — la chaîne se place entre les deux.
La chaîne d'industrialisation — le durcir
- I Entrée dans la chaîne
Rien ne la contourne. Elle refuse de démarrer sans une base de code qui compile depuis un clone propre, ses étiquettes renseignées, et une personne nommée qui puisse en répondre.
- II C'est planifié
Ce qu'industrialiser cette chose veut dire est écrit avant que rien ne change. Ce plan est ce dont tout le reste part, et ce qu'une personne lit quand une décision s'impose.
- III C'est durci
Un prototype devient du logiciel de production. C'est l'étape qui change les réponses de sécurité et d'infrastructure, et c'est la même étape pour chaque projet.
- IV Des humains, seulement s'ils sont demandés
L'ingénieur qui l'a construit, avec le Head of Engineering — pas un comité de revue permanent. Leur second travail : s'assurer que le constructeur comprend ce qui a été construit. Une transmission écrite par quelqu'un qui ne comprend pas n'est pas une transmission.
- V Tests, sécurité, déploiement
Une barre à 100 % au vert. La machine décide que c'est fait ; une personne décide que ça part.
Moitié 2 · Tech Lab — le garder en vie
- 7 Transmission à un binôme
Un Product Owner et un développeur reprennent quelque chose qu'ils n'ont pas construit — ce qui ne marche que parce que chaque produit arrive avec la même forme. Ils l'acceptent en le testant.
- 8 Le porter, le construire, l'exploiter
En continu. Le PO tient la relation métier, le backlog et la recette ; le développeur tient la construction, l'architecture et la mise en production. Un produit qui cesse d'évoluer cesse d'être utilisé.
- 9 Sortie de scène, s'il part un jour
Certains produits se stabilisent et n'ont plus besoin de vélocité. Partir est un chemin nommé, décidé au cas par cas, jamais une dérive. Une condition de réussite, pas un échec.
Deux règles qui donnent le rythme
- L'horloge, c'est le processus, pas le calendrier
- Des jours pour quelque chose de simple, un trimestre pour quelque chose de réellement difficile — fixé par le score de complexité à la réception. Un délai court sur un processus non examiné ne rend pas le travail plus rapide ; il fait arriver la première conversation honnête plus tard. Et un non honnête est un résultat livré : si la valeur n'y est pas, nous arrêtons et nous l'écrivons.
- Chaque présentation commence par dire ce que ce n'est pas
- Ce que cela fait, et ce que cela ne fait explicitement pas sur la sécurité, l'infrastructure et les données — annoncé avant la démo, pas après. Dix minutes après avoir vu du logiciel qui marche, une réserve sonne comme un rétropédalage ; dite d'abord, elle sonne comme un périmètre. Cela compte surtout au quasi-MVP, qui a l'air bien plus fini qu'il n'est sûr.
Ce que contient réellement une transmission
Le dossier de transmission n'est pas un dossier. C'est le dépôt, plus les choses qu'un dépôt ne peut pas contenir. L'essentiel s'écrit pendant l'étape qui le produit, il ne s'assemble pas à la fin.
- Le dépôt
- Pas un dossier de documents — le dépôt lui-même : porte d'entrée, index de la documentation et ordre de lecture, l'architecture, et un journal des décisions consignant ce qui a été choisi, pourquoi, et ce qui déclencherait un réexamen.
- Quatre documents produit
- La cartographie du processus tel qu'il est réellement fait. L'architecture fonctionnelle. Le cas de bénéfice avec sa base de référence mesurée. La cartographie des parties prenantes : qui se soucie de quoi, et qui appeler quand ça casse.
- La déclaration de profondeur technique
- Ce qui a été relu et par qui — ou franchement, que rien ne l'a été. Là où la conception est restée superficielle, et les manques que le constructeur connaît déjà.
- Le runbook
- Déploiement et retour arrière, exécutés plutôt que décrits. Chaque alerte et ce qu'elle veut dire. Les trois choses les plus susceptibles de casser. Le compte rendu de l'exercice de restauration.
- La feuille de route
- Ce qui n'a délibérément pas été construit, et pourquoi.
- Les parcours de prise en main
- Un chemin de première utilisation dans le produit, un mode d'emploi d'une page pour la tâche la plus courante, et le premier groupe d'utilisateurs nommé, réellement pris en main avant la transmission.
- Six champs de registre
- Des responsables qui correspondent à de vraies personnes. Palier de taille contraignant, classification des données, niveau de risque, écarts déclarés — et une condition de retrait, jamais vide.
- Deux réunions bornées
- Une traversée enregistrée de quatre-vingt-dix minutes et une présentation aux parties prenantes. Puis cela s'arrête.
Le dossier s'accepte en le testant
Un démarrage à froid : le développeur qui reçoit, seul, depuis un clone, sans personne à qui demander, le met en marche et livre une modification triviale. Tant que cela ne passe pas, le constructeur n'est pas sorti. Ensuite il répond des défauts du dossier et jamais des questions produit — une question à laquelle seul le constructeur peut répondre est le défaut. Puis il part complètement.
L'affectation suit un score, pas un avis
La taille est un score composite sur trois axes — la surface (jusqu'où porte le rayon d'impact), la charge d'exploitation (ce que cela coûte de le porter) et la complexité de construction — et non une négociation. La complexité est délibérément la moins pondérée : là où les agents construisent l'essentiel, l'effort de construction est l'intrant bon marché et la prise en charge est la ressource rare.
Le palier fixé à la réception est une prévision. Il est renoté à la transmission par des gens qui ont construit la chose et vu de vrais utilisateurs y toucher, et c'est celui-là qui engage. Un binôme hérite d'un palier, pas d'un avis.
Quelque chose dans votre entreprise
qui ne devrait pas être manuel ?
Dites-nous comment le travail se déroule vraiment aujourd'hui. S'il y a quelque chose à faire, vous le saurez en quelques jours plutôt qu'en quelques trimestres.