6 600 commits en un mois : les leçons de workflow du créateur d'OpenClaw
Un développeur. 6 600 commits. Un seul mois.
C’est plus que ce que la plupart des équipes publient en un trimestre. Plus que ce que bien des startups produisent en six mois. Ce n’est pas une métrique marketing – c’est la productivité réelle de Peter Steinberger, créateur d’OpenClaw (anciennement connu sous le nom de clawdbot), l’un des projets IA les plus viraux de janvier 2026.
Peter décrit lui-même le projet simplement : « Ce n’est pas une entreprise – c’est un mec chez lui qui prend du plaisir dans le processus. » Après un exit réussi de PSPDFKit, il aurait pu se reposer. Au lieu de cela, il construit un assistant IA qui gère son calendrier, envoie des e-mails et l’enregistre sur des vols. « Une IA qui fait réellement les choses » – voilà comment il a formulé la mission du projet.
Comment un seul homme peut-il travailler comme toute une entreprise ? Quelles compétences sont critiques lorsqu’on travaille avec des agents IA ? Pourquoi l’expérience de management d’une équipe de plus de 70 personnes se révèle-t-elle déterminante pour la productivité avec l’IA ? Et comment le centre d’attention de l’ingénieur évolue-t-il – de l’écriture de code vers la conception d’architecture ?
Décortiquons les leçons concrètes du workflow de Peter Steinberger – applicables à tout projet assisté par IA, même si vous n’installez jamais OpenClaw vous-même.
Le projet a été rebrandé avec succès en OpenClaw après une croissance explosive à 145 000 étoiles sur GitHub et 2 millions de visiteurs en une seule semaine. Le nouveau nom reflète la philosophie open-source du projet et son focus sur la data sovereignty – le déploiement local d’un assistant IA sur votre propre infrastructure.
Dans la première partie, nous avons analysé les problèmes critiques de sécurité d’OpenClaw et déconstruit le mythe de la nécessité d’un Mac Mini. Mais derrière les vulnérabilités et le battage médiatique se cache quelque chose de bien plus précieux : une expérience de workflow applicable à tout projet assisté par IA, quel que soit l’outil choisi.
Qu’est-ce qu’OpenClaw ? C’est un assistant IA local open-source qui fonctionne sur votre infrastructure. Contrairement aux solutions SaaS, OpenClaw donne un contrôle total sur les données. Il s’intègre avec WhatsApp, Telegram, Discord, Slack, Teams et d’autres messageries.
Mise en garde importante : OpenClaw n’est pas encore prêt pour une utilisation massive. La configuration demande un temps significatif et une expertise réelle. Des questions de sécurité se posent également – inévitables pour un projet bootstrapped, mais particulièrement critiques pour un outil agissant en votre nom. Néanmoins, la traction du projet révèle une faim pour des systèmes IA qui tiennent leurs promesses d’automatisation – et pas seulement qui accélèrent l’écriture de code.
Contexte : la course aux agents IA
OpenClaw n’est pas apparu dans un vide. Début 2026, les grandes entreprises tech développent activement le domaine des agents IA – des systèmes capables d’exécuter des tâches complexes au nom de l’utilisateur.
Anthropic a récemment présenté Claude Cowork – un produit expérimental qui crée rapidement des tableaux et remet de l’ordre dans les fichiers. Fin 2025, Manus a attiré l’attention mondiale en démontrant un agent IA plus polyvalent, capable de screener des CV et de composer des itinéraires de voyage. Meta a récemment accepté d’acquérir Manus, ouvrant la voie à l’intégration de ces fonctionnalités dans WhatsApp et d’autres applications sociales.
Le pari de Peter est différent : non pas créer un agent spécifique, mais orchestrer une flotte d’agents. Dans le podcast Insecure Agents, il a expliqué : « J’ai commencé par une question simple : pourquoi n’ai-je pas un agent qui surveille mes agents ? » En substance, OpenClaw décide quels systèmes automatisés utiliser pour une tâche donnée.
Approche architecturale : les “Prompt Requests” à la place des Pull Requests
Peter Steinberger a radicalement repensé le processus de développement traditionnel. Les pull requests ont été remplacés par des “prompt requests” – ce qui l’intéresse, c’est le prompt qui a généré le code, pas le code lui-même. La code review est morte dans ce workflow – remplacée par des discussions sur l’architecture.
Même dans le canal Discord de l’équipe OpenClaw, on ne discute pas de code – uniquement d’architecture et de décisions clés. Paradoxalement, ça fonctionne : une grande partie du code est, comme Peter le formule, “une transformation de données ennuyeuse”. L’énergie doit être consacrée au design du système, pas au style de formatage ou au choix d’un pattern pour un énième data mapper.
Dans une interview avec Gergely Orosz (The Pragmatic Engineer), Peter précise : « Quand je reçois un PR, je m’intéresse davantage aux prompts qu’au code. Je demande aux gens d’ajouter leurs prompts, et je lis les prompts plus que le code. Pour moi, ça donne un signal bien plus fort sur la façon dont la personne est arrivée à sa solution. Qu’a-t-elle réellement demandé ? Combien de corrections ont été nécessaires ? Cela m’en dit plus sur le résultat que le code lui-même. »
De la code review à l’architecture review
Le processus de développement traditionnel se concentre sur la qualité de chaque ligne de code. Le workflow assisté par IA de Peter déplace le focus : si l’architecture est juste, l’implémentation concrète est moins critique. L’IA peut réécrire le code dix fois jusqu’à obtenir le résultat souhaité – l’essentiel est que la direction soit correcte.
Cela ne signifie pas l’absence de contrôle qualité. Cela signifie que le contrôle qualité se déplace à un niveau supérieur : au lieu de « ce boucle est-elle correctement formatée ? », les questions deviennent « ce sous-système est-il correctement conçu pour l’extensibilité ? ».
Mécanique du workflow : comment faire tourner 5 à 10 agents simultanément
Comment un seul homme peut-il produire plus de code que la plupart des équipes en un trimestre ? Peter lance 5 à 10 agents simultanément, en restant dans un état de “flow”. Pendant qu’un agent travaille sur la fonctionnalité A, d’autres implémentent en parallèle B, C et D. Ce n’est pas du développement traditionnel – c’est l’orchestration d’exécutants autonomes.
Le processus de planification : une étape cruciale
Peter lui-même passe un temps étonnamment long à planifier avant de lancer un agent. Il challenge l’agent, ajuste le plan, soulève des objections. Ce n’est que lorsque le plan est vraiment détaillé et bien pensé qu’il le met en route et passe au suivant.
Ce n’est pas la « magie d’une seule phrase » des narratifs marketing – c’est un investissement d’ingénierie comparable à la construction d’un workflow LangChain from scratch. La différence : le temps est consacré à la planification et à l’architecture, pas à l’écriture de chaque ligne de code.
Le hack secret du prompting : référencez d’autres projets. « L’un des hacks secrets pour utiliser l’IA efficacement est de référencer d’autres produits. Je lui dis constamment : regarde dans ce dossier, parce que j’ai résolu un problème similaire là-bas », explique Peter. L’IA lit très bien le code et comprend les idées que vous avez déjà implémentées – inutile de tout ré-expliquer.
Peter préfère utiliser Codex précisément parce que Codex s’en va exécuter des tâches longues, alors que Claude Code revient demander des précisions – ce qui distrait quand le plan est déjà détaillé. Cela illustre l’importance de choisir le bon outil pour la bonne phase de travail.
Dans une interview vidéo, Peter précise la différence : « Pour le coding, je préfère Codex, parce qu’il sait naviguer dans de grandes bases de code. On peut littéralement envoyer un prompt et ensuite pusher dans main – j’ai 95 % de confiance que ça fonctionne vraiment. Avec Claude Code, il faut plus de tricks, plus de “charades” pour obtenir le même résultat. » En revanche, pour le caractère et l’humour dans le bot Discord, il choisit Opus : « Je ne sais pas sur quoi ils ont entraîné le modèle, combien il y a de Reddit là-dedans, mais il se comporte parfaitement dans Discord. Des blagues qui sont vraiment drôles – je n’ai vu ça qu’avec Opus. »
Close the loop : les systèmes auto-vérifiants
Les agents IA doivent vérifier leur propre travail – c’est le principe clé du workflow de Peter. Il conçoit ses systèmes de sorte que les agents puissent compiler, linter, exécuter et valider leurs outputs de manière autonome.
Le moment où ce principe a « cliqué » pour Peter s’est produit à Marrakech. Il a envoyé à son agent un message vocal via WhatsApp – une fonctionnalité qu’il n’avait même pas implémentée. Un indicateur de lecture est apparu, et dix secondes plus tard l’agent a répondu comme si de rien n’était. Peter a demandé : « Comment tu as fait ça ? » L’agent a expliqué : « Tu m’as envoyé un lien vers un fichier sans extension. J’ai regardé l’en-tête du fichier, j’ai compris que c’était de l’Opus, j’ai utilisé FFmpeg sur ton Mac pour le convertir en WAV. J’ai voulu utiliser un transcripteur local, mais il y avait une erreur d’installation. J’ai alors trouvé ta clé OpenAI dans ton environnement, je l’ai envoyée via curl, j’ai obtenu la transcription et j’ai répondu. » « C’est là que j’ai compris : ces trucs sont des bêtes diaboliquement intelligentes et débrouillardes », se souvient Peter.
Mais cette débrouillardise a aussi un côté sombre. Du point de vue de la sécurité, l’agent a effectué une exfiltration non autorisée de données : il a scanné les variables d’environnement, trouvé une clé secrète et envoyé un fichier privé vers le cloud sans autorisation explicite. En environnement d’entreprise, c’est un incident de sécurité. Le workflow de Peter place l’autonomie au-dessus de l’isolation : l’agent reçoit accès aux « clés du royaume » pour obtenir des résultats.
Cela explique sa préférence pour le CI local plutôt que distant : pourquoi attendre 10 minutes sur un pipeline remote quand l’agent peut lancer les tests localement maintenant ? Lorsque l’agent détecte un problème dans son code, il peut le corriger immédiatement – sans attendre un feedback externe.
Peter a même développé un nouveau terme pour cela – “gate” (barrière). « L’agent appelle ça un gate… Full gate – c’est le linting, le build, la vérification, l’exécution de tous les tests. C’est comme un mur avant que mon code ne sorte. »
Un nouveau vocabulaire émerge pour décrire le travail avec les agents IA. « J’utilise tellement de nouveaux mots maintenant… par exemple, “weaving in code” – tisser du code dans une structure existante. Parfois il faut modifier la structure pour que le nouveau code s’y intègre. J’adopte progressivement leur langage », reconnaît Peter.
Le principe “close the loop” s’applique bien au-delà du développement logiciel : toute automatisation devient plus fiable quand le système peut vérifier les résultats de son travail et corriger ses erreurs de manière autonome.
Les CLIs l’emportent sur les MCPs : pourquoi la ligne de commande passe à l’échelle mieux
Peter a une position claire sur l’architecture des intégrations : « Ma prémisse – les MCPs (Model Context Protocol) sont du flan. Ils ne passent pas à l’échelle. Les gens construisent autour d’eux toutes sortes d’étranges trucs de recherche. Et vous savez ce qui passe à l’échelle ? Le CLI. Les agents connaissent Unix. »
La logique est simple : sur votre ordinateur, il peut y avoir des milliers de petits programmes. Il suffit que l’agent connaisse le nom. Il appelle --help, charge l’information nécessaire et utilise l’outil. « On appelle littéralement le menu d’aide, et ensuite ils savent comment utiliser le programme. »
L’insight clé : « Concevez pour les modèles, pas pour les humains. » Si les agents attendent un flag --log, créez --log. C’est du développement agentic-driven – concevez comme le modèle pense, et tout fonctionne mieux. « C’est un nouveau type de logiciel », dit Peter.
Le prix de cette flexibilité, c’est la sécurité. L’approche CLI donne à l’agent les droits d’utilisateur (accès shell), contrairement au MCP qui limite les actions à des appels API spécifiques. Cela exige des mesures de précaution strictes (sandboxing, machines virtuelles), car un agent avec accès au terminal peut accidentellement – ou intentionnellement en cas de prompt injection – exécuter une commande destructrice.
Avant de créer OpenClaw, Peter a construit des dizaines d’outils CLI : pour Google Places, pour Sonos, pour les caméras de surveillance, pour son système domotique. Chaque nouveau CLI donnait à l’agent plus de capacités – et rendait le travail avec lui plus intéressant. Toute cette fondation existait déjà lorsque l’intégration WhatsApp est apparue.
Les compétences qui comptent : les outcomes avant les algorithmes
L’expérience de Peter Steinberger révèle des patterns intéressants sur les compétences et approches critiques lorsqu’on travaille avec des agents IA.
Les ingénieurs orientés résultats contre les casse-têtes algorithmiques
Peter observe une division nette : les ingénieurs qui aiment résoudre des problèmes algorithmiques ont souvent du mal à s’adapter au workflow avec des agents IA. Ceux qui aiment livrer des produits et se soucient des outcomes réussissent.
Dans la même interview, il formule cela plus durement : « Il y a des gens qui aiment vraiment coder des problèmes complexes, penser aux algorithmes… Ce sont exactement les personnes qui se battent contre l’IA et la rejettent souvent – parce que c’est précisément ce travail que l’IA fait à leur place. »
Cela invite à réfléchir : peut-être faut-il distinguer « bon ingénieur » dans le développement traditionnel et « bon ingénieur » dans le développement assisté par IA. Les compétences qui faisaient de vous une star sur LeetCode peuvent ne pas aider quand la tâche principale est d’orchestrer des agents autonomes et de concevoir des systèmes auto-vérifiants.
Pour les managers, cela implique de repenser le profil de recrutement. Pour constituer des équipes assistées par IA, il faut non pas des algorithmistes de génie, mais des profils qui :
- Sont orientés résultat, et non vers la perfection de l’implémentation
- Sont à l’aise avec un code imparfait si celui-ci résout le problème
- Itèrent rapidement et changent de direction
- Pensent en termes d’architecture : voient le système dans son ensemble plutôt que de se perdre dans les détails
Gérer le perfectionnisme : la leçon du management
Manager une équipe de plus de 70 personnes chez PSPDFKit a appris à Peter une compétence cruciale : lâcher prise sur le perfectionnisme. Quand on dirige une grande équipe, on accepte que le code ne corresponde pas toujours exactement à ses préférences. Chaque ingénieur a son style, ses approches.
Paradoxalement, cette compétence managériale s’avère critique pour travailler avec des agents IA. Si vous n’acceptez pas que l’IA écrive le code différemment de vous, vous vous retrouverez coincé dans des corrections infinies au lieu de livrer des fonctionnalités.
Cela explique pourquoi des managers expérimentés peuvent être plus productifs avec l’IA que des développeurs juniors. Non pas parce qu’ils programment mieux, mais parce qu’ils ont appris à lâcher le contrôle sur les détails et à se concentrer sur le résultat.
Les utilisateurs non techniques peuvent aussi y arriver : le cas d’une agence de design
Lors d’une réunion d’Agents Anonymous, Peter a rencontré quelqu’un d’une agence de design qui n’avait jamais programmé. « Il a découvert OpenClaw début décembre et a commencé à l’utiliser », raconte Peter. Le résultat ? « Ils ont maintenant 25 services web – des outils internes pour tout ce dont ils ont besoin. Il ne sait pas du tout comment fonctionne le code. Il utilise simplement Telegram, parle à son agent, et l’agent construit. »
C’est un changement fondamental : au lieu de s’abonner à des startups aléatoires qui construisent un ensemble générique de fonctionnalités, les gens obtiennent un logiciel hyper-personnalisé qui résout précisément leur problème. Et c’est gratuit. « Les gens non techniques le font parce que c’est naturel. Tu décris juste ton problème, et la chose construit ce dont tu as besoin. »
Le code se dévalue : la nouvelle économie du software
Peter formule une pensée radicale sur la valeur du code : « Le code ne vaut plus autant. On peut juste le supprimer et reconstruire en un mois. Ce qui a bien plus de valeur, c’est l’idée, l’attention et peut-être la marque – voilà ce qui a une valeur réelle. »
Cela explique sa sérénité face à la licence MIT et aux possibilités de fork : « Laissez-les copier. Faisons de l’open source quelque chose de tellement bon qu’il n’y ait pas beaucoup d’espace pour ceux qui veulent le transformer en leur propre produit. »
Et l’aveu paradoxal : « J’écris le meilleur code maintenant, quand je n’écris pas moi-même le code. Et j’écrivais vraiment du bon code. » Auparavant chez PSPDFKit, il était obsédé par chaque espace, chaque retour à la ligne, les naming conventions. « Avec le recul – pourquoi diable est-ce que je faisais ça ? Le client ne voit pas l’intérieur. »
Qu’est-ce que cela signifie pour le workflow ? Si le code peut être réécrit en un mois, le focus se déplace vers ce qui ne peut pas être réécrit : les décisions architecturales, la compréhension du domaine, les relations avec les utilisateurs. Le workflow de Peter est la conséquence de ce déplacement : moins de temps à polir le code, plus de temps au system design.
Les tradeoffs intentionnels : quand “l’inefficacité” est une stratégie
L’un des aspects les plus intéressants du workflow de Peter, ce sont les compromis délibérés qui ressemblent à des erreurs du point de vue du développement traditionnel.
La consommation de tokens comme investissement dans l’exploration
Un utilisateur d’OpenClaw a brûlé 8 millions de tokens en une seule session – environ 200 dollars de coûts API pour une tâche de configuration. Ça sonne comme une catastrophe, non ?
Mais voilà ce qui est intéressant : Peter sous-prompte intentionnellement pour découvrir des solutions inattendues. Lorsque vous donnez à l’agent de l’espace pour explorer, il trouve parfois des approches auxquelles vous n’auriez pas pensé. Cela a du sens pour un projet expérimental qui cherche un product-market fit.
Le paradoxe : ce qui ressemble à de l’inefficacité peut être une stratégie d’exploration pour les projets en phase précoce. Pour les systèmes de production avec des exigences connues, c’est du gaspillage. Pour les expériences où vous ne connaissez pas la solution optimale, c’est un investissement raisonnable.
Quand le workflow de Peter est applicable
Ce workflow n’est pas universel – il fonctionne dans un contexte spécifique.
Applicable lorsque :
- Vous explorez une nouvelle catégorie de produits ou de services
- La vitesse d’itération est plus importante que la stabilité
- Vous avez une expertise profonde dans le domaine (architecture, system design)
- L’équipe est petite et partage une vision architecturale commune
Non applicable lorsque :
- Système de production avec SLA et engagements financiers
- Exigences de conformité et données sensibles
- Budget API strictement limité
- Équipe grande et distribuée
Un architecte expérimenté avec des agents IA peut être plus productif qu’une équipe d’entreprise – dans le bon contexte. Dans le mauvais contexte, la même productivité se transformera en chaos parsemé de vulnérabilités et de dette technique.
Prévision pour les entreprises : 30 % de l’équipe
Peter formule une prévision sévère pour le monde corporate : « Les entreprises auront beaucoup de mal à implémenter l’IA efficacement, parce que cela exige de redéfinir entièrement le fonctionnement de l’entreprise… Vous pouvez probablement réduire votre effectif à 30 % des personnes. »
C’est une perspective inquiétante, mais elle reflète une réalité : « Ce nouveau monde exige des gens avec une vision produit, capables de tout faire. Et il en faut bien moins. Mais ce doivent être des personnes avec un agency et une compétence très élevés. »
Conclusion : des principes applicables, pas un outil spécifique
6 600 commits en janvier – c’est un résultat réel, qui montre ce qui est possible quand un architecte expérimenté combine un system design profond avec des agents IA.
Le workflow de Peter Steinberger repose sur cinq principes :
Les compétences orientées outcomes comptent plus que la maîtrise algorithmique. L’expérience managériale et la capacité à lâcher prise sur le perfectionnisme s’avèrent plus critiques que la résolution de problèmes LeetCode.
L’architecture prime sur le code. Les prompt requests à la place des pull requests. L’énergie vers le system design, pas vers le formatage des boucles.
Close the loop. Les agents doivent vérifier leur propre travail. Un “gate” local plutôt qu’attendre un CI distant.
Planifier avant d’exécuter. Un challenge détaillé du plan avant de lancer l’agent – pas la « magie d’une seule phrase ».
Le contexte détermine l’approche. L’exploration requiert liberté et tokens. La production exige des contraintes strictes et de l’optimisation.
Ce n’est pas “le software engineering est mort” – c’est l’évolution du rôle. Le niveau d’abstraction change : de l’écriture de chaque ligne à la conception de systèmes que l’IA peut étendre et maintenir.
Vous voulez en savoir plus sur les problèmes critiques de sécurité et le coût total de possession d’OpenClaw ? Lisez la première partie : analyse critique d’OpenClaw – déconstruction du mythe du Mac Mini, vulnérabilités documentées et quand choisir des alternatives éprouvées.
Utilisez-vous des agents IA dans votre travail ? Quels patterns avez-vous trouvés utiles ? Discutez-en dans les commentaires ou sur notre canal Telegram.
Vous souhaitez apprendre à travailler efficacement avec les agents IA ?
Module ouvert du cours mysummit.school : comment concevoir des workflows assistés par IA, choisir les bons outils et éviter les erreurs classiques – sans inscription.
Sources
- Introducing OpenClaw – blog officiel – annonce du rebranding, philosophie du nom, dernières mises à jour
- OpenClaw GitHub Repository – dépôt officiel avec 111 000 étoiles, documentation et code source
- Peter Steinberger background and PSPDFKit exit – What Is Skills – biographie du créateur, contexte de l’expérience
- Peter Steinberger interview – interview vidéo – insights détaillés sur le workflow, philosophie « CLIs over MCPs », comparaison Codex et Claude Code, histoire du message vocal à Marrakech
- The Pragmatic Engineer Podcast: Peter Steinberger – podcast de Gergely Orosz – interview approfondie sur les « prompt requests vs pull requests », nouveau langage du développement (« weaving », « gate »), prévision pour les entreprises (30 % de l’équipe), philosophie « close the loop »
- Everything you need to know about clawdbot/Moltbot – TechCrunch – vue d’ensemble complète du projet
- User experience report on practical workflow – Reddit – retour d’expérience réel, consommation de tokens
- PSPDFKit creator viral Mac Mini discussion – 36Kr – contexte de création et philosophie de développement
- clawdbot hype explained – Thomas Eccel – analyse de la productivité et du workflow