1Health est en BETA aux Émirats aujourd'hui : découverte de patients, annuaires de praticiens, back-office fournisseur, niveaux d'annonce et système de marque dans le produit. Il y a douze mois, c'était une conversation familiale. Le build qui signifiait autrefois une équipe financée et un plan de recrutement, c'est surtout moi, plus des agents auxquels je ne fais confiance que dans la mesure où je peux lire leurs diffs.

On me demande encore si une personne, ou un développeur, peut faire tourner une vraie entreprise avec l'IA. J'ai arrêté d'en débattre et j'ai livré. Ceci est un compte rendu terrain sur ce qu'est vraiment le travail quand la première version est bon marché : pas une prédiction, et pas un pitch pour remplacer votre équipe.

Vous pouvez décrire une app en un paragraphe et avoir quelque chose qui tourne l'après-midi même. C'est une semaine normale en 2026. Les derniers modèles d'Anthropic peuvent livrer en une passe des builds qui prenaient un sprint entier à mon équipe il y a deux ans. L'ancienne question était de savoir si les développeurs étaient finis. La question utile est ce qui a changé dans le travail quand les machines ont pris la frappe et vous ont laissé tout le reste.

Ce que signifie « première version » maintenant

Il y a deux ans, le code IA voulait dire l'autocomplétion. Aujourd'hui vous décrivez le résultat et un agent fait le reste. Un agent est une IA qui peut planifier, écrire des fichiers, lancer ses propres tests et corriger ses propres erreurs sans que vous regardiez. Des outils comme Claude Code et les agents de type Cursor vous remettent du logiciel qui marche assez souvent pour que le volume de code ne soit plus la contrainte.

Mais « première version » ce n'est pas que du code. C'est aussi un parcours UX qui compile mais rate le job. C'est une fonctionnalité d'une slide roadmap que personne n'a demandée. Trois versions, même test : quelque chose de plausible arrive vite ; quelqu'un doit encore décider si c'est vrai.

L'industrie l'a vu venir. En mars 2025, le CEO d'Anthropic Dario Amodei a prédit que l'IA écrirait 90 % du code en quelques mois. Il a ajouté une phrase moins relayée : « Le programmeur doit encore préciser les conditions de ce que vous faites, quelle est l'app globale que vous essayez de construire, quelle est la décision de design globale. » La première partie a fait les gros titres. La seconde est la fiche de poste des fondateurs comme des ingénieurs.

L'organigramme à un

Une entreprise à une personne ne veut pas dire que les jobs ont disparu. Ça veut dire que vous les tenez tous, et que les agents n'ont pris qu'un seul : la frappe.

Quelqu'un décide encore quoi construire. Quelqu'un décide qui peut voir les informations d'un patient, parce qu'en santé cette question a un corps attaché. Quelqu'un décide ce qu'une clinique paie et ce qui reste gratuit. Quelqu'un décide ce qui se passe quand une réservation échoue la nuit avec une vraie personne qui attend. Quelqu'un répond au mail support. Quelqu'un est légalement responsable.

Un agent décidera de tout ça pour vous si vous le laissez faire. Il décide avec une supposition. La supposition compile, démo bien, et est fausse de façons que vous découvrez via un utilisateur ou un diff.

Ma journée ressemble plus à du management qu'à de l'ingénierie. Je planifie le travail et laisse un agent découper les tickets sur le board. Je lis les plans avant qu'aucun code ne soit écrit. Je lis les diffs, jamais les résumés, parce que le résumé est l'histoire que l'agent veut raconter et le diff est ce qui s'est passé. Je chasse les fallbacks et les stubs que les agents laissent quand ils n'étaient pas sûrs que leur vraie approche tiendrait. Je tue les sessions fatiguées et j'en ouvre de nouvelles. Cette boucle de vérification, c'est un tiers de ma semaine, chaque semaine.

Les agents ont pris la frappe. J'ai gardé tout le reste. Le tout le reste s'est avéré être l'entreprise.

1Health : quand les agents écrivent le scaffolding

Andrej Karpathy a donné un nom à cette façon de construire :

Le vibe coding est passé d'un tweet jetable à une entrée de dictionnaire, et je construis ainsi au quotidien. 1Health a démarré comme une fondation vibecodée : les agents ont écrit la majeure partie du scaffolding applicatif, du routing et de l'UI early. J'ai gardé la connexion, les réservations, la sécurité admin et chaque parcours patient qui touche à la confiance.

La vitesse n'a jamais été notre problème. Les questions lentes étaient les nôtres. Qui peut voir les informations d'un patient ? Que paie une clinique, et qu'est-ce qui reste gratuit ? Que doit-il se passer quand une réservation échoue la nuit ? Un agent répondra à ça aussi, avec une supposition qui paraît confiante jusqu'à ce que vous lisiez le diff et trouviez un stub là où une vraie politique de retry devrait être.

La santé ne pardonne pas les suppositions sur ces bords. J'ai gardé le jugement sur l'UX en domaine régulé, les niveaux fournisseur et le back-office admin derrière les annonces et les comptes. Pitch et projections financières ont avancé en parallèle pour que l'histoire sur les slides corresponde au build. C'est la texture du job : pas des astuces de prompt, mais du jugement sous charge sans personne pour rattraper ce que vous ratez.

Paper : quand la première version du parcours était fausse

Chez Paper, le même test est apparu avant les agents de code. La génération bloquait rarement. Le vrai test était de savoir si une fonctionnalité aidait un professeur un jour d'école ordinaire et tenait sur tout un district.

Les élèves atterrissaient sur un écran blanc avec une boîte leur demandant de choisir un sujet. Ils hésitaient. Nous avons superposé le sélecteur de sujet sur un aperçu du chat en dessous. Les démarrages de session ont augmenté d'environ 25 %. Les élèves ont dit que c'était évident avec le recul. J'ai écrit davantage sur ce correctif dans Une bonne UX s'efface. Un quart du polish de la roadmap n'a pas bougé la rétention autant.

Nous avons construit Paper Review parce que les tuteurs révisaient déjà des copies à la main dans le chat. Les élèves demandaient sans cesse si quelqu'un pouvait aider sur leur copie. Un parcours dédié a fait gagner 30 %+ de temps aux profs et est devenu le flagship de l'entreprise. Personne ne l'a deviné sur un tableau blanc. La demande était déjà dans le produit.

Les agents de code ont amené le même test à tous ceux qui livrent du logiciel. La première version du code, de l'écran ou de la fonctionnalité peut arriver en heures. La seconde version vient encore de regarder de vraies sessions.

Comment je gère le volume

Quand les agents produisent migrations, composants, tests et glue en parallèle, le débit n'est plus le goulot. La coordination et la mémoire le sont.

Je traite le board comme source de vérité sur ce que « fait » veut dire cette semaine. Plans avant code. Je relis le plan comme je relisais un brief de sprint, puis je laisse un agent exécuter. Sans cette étape, vingt agents parallèles deviennent vingt visions produit en conflit.

MCP, le Model Context Protocol, permet aux agents d'appeler des outils externes au lieu de deviner. Logs de déploiement, DNS, email, requêtes base : l'agent lit l'état du système, pas sa dernière conversation. J'utilise des hooks MCP pour les audits infra et les checks prod pour que « ça devrait marcher » devienne « voici la réponse API ».

Les sessions sont stateless. Les instructions cadrées ne le sont pas. Règles écrites, skills et checklists sont la base de données de comment on travaille : quoi vérifier, quoi ne jamais committer, quelles env vars comptent. Elles survivent aux redémarrages de session pour que le prochain agent ne rouvre pas des décisions déjà prises.

Pour les produits lourds en contenu et données, je garde une vraie base comme vérité : les seed files se synchronisent dans SQLite, l'API sert ce qui est livré, et je vérifie le build avant d'appeler ça fait. Le process remplace les collègues comme système de correction d'erreurs. Une équipe est plus lente, mais une équipe attrape aussi les angles morts. J'ai reconstruit cette fonction avec des boards, des diffs et des audits de fin de session.

Ce qu'est le job développeur maintenant

Le goulot a bougé. Avant c'était la vitesse à laquelle vous pouviez construire. Maintenant c'est la vitesse à laquelle vous pouvez décider et vérifier. Ma plateforme shippe exactement à la vitesse où je peux lire des diffs, répondre à des questions dures et vérifier que fait veut dire fait.

C'est du goût et de la pensée critique sous un autre nom. Le goût, c'est savoir quelle supposition d'agent correspond au produit que vous livreriez. La pensée critique, c'est demander pourquoi avant de corriger, parce que le raté montre où l'agent devine et cette connaissance se cumule plus vite que n'importe quelle astuce de prompt.

J'ai passé vingt ans entre design, produit et leadership technique avant ça : VP Product chez Paper, co-fondateur et CTO chez Openfair, où nous avons atteint 1 M$+ d'ARR en environ douze mois. Chacun de ces jobs était un entraînement au jugement. Les agents ont rendu tout ça soudainement pertinent, parce que je prends en une semaine l'étendue de décisions qui était répartie sur une équipe de direction.

Chez Openfair, un agent pouvait nous donner une démo en un jour. De vrais utilisateurs, de vraies données et de l'argent réel posaient encore une barre plus haute. L'écart entre la démo et cette barre est là où les produits gagnent la confiance. Le même écart a coulé le hardware IA early ; j'en ai parlé dans Leçons hardware IA de Humane et Rabbit.

Des pratiques qui tiennent la vitesse

Si vous construisez avec des agents en tant que développeur ou fondateur-opérateur, ces habitudes portent l'essentiel du poids :

• Écrivez ce que « fait » veut dire avant de prompter. Règles de données, comportement en échec, qui voit quoi. L'agent remplit le milieu ; la définition est la vôtre.
• Lisez les diffs, pas les résumés. Le résumé est l'histoire que l'agent veut raconter. Le diff est ce qui s'est passé.
• Gardez chaque changement assez petit pour être revu. Relisez le diff comme vous relisiriez le travail d'un collègue. C'est ce que c'est maintenant.
• Mettez les plans sur le board avant le code. Une source de vérité pour le scope de la semaine bat vingt agents confiants.
• Quand la sortie rate, demandez pourquoi avant de corriger. Les ratés cartographient où l'agent devine.
• Utilisez MCP pour la vérité externe. État de déploiement, bases, APIs : lisez le système, ne faites pas confiance à la mémoire du chat.

Une entreprise à une personne, c'est une équipe compressée en un seul point de jugement. Les agents sont les mains. Chaque paire de mains bouge à vitesse machine. Chaque décision sur si c'est réel, ou juste habillé pour paraître réel, passe encore par un humain.

Si vous apportez du jugement forgé par des années dans un domaine, l'effet de levier est absurde. Si vous espérez que l'IA fournisse le jugement, vous obtenez quelque chose qui ressemble à une entreprise comme le code agent ressemble à fait. Le marché joue le même rôle que moi en revue de code, sauf que le marché facture la leçon plus cher.

Si vous apprenez à coder, continuez, et apprenez avec des agents dès le premier jour. Construisez une petite chose de bout en bout chaque semaine. La carrière qui vaut la peine est dans la vérification et le goût, pas la vitesse de frappe.

Si vous livrez un produit maintenant et que la forme est encore floue, j'aide les fondateurs à clarifier le prochain mouvement. Dites-moi ce que vous construisez.

Publié initialement dans la newsletter Product, AI & Business sur LinkedIn.