Doctolib recently conducted a one-week experiment to see how agentic AI could reshape developer workflows – moving from asynchronous processes to a synchronous, AI-collaborative model. Three senior staff (a senior engineer, a staff engineer, and an engineering manager) worked together in a virtual room with screens shared continuously, aiming to clear a backlog originally estimated at six weeks of work. The result was a claimed 2× acceleration, with 10 of 13 planned tasks reaching production.

Preparation began with building a knowledge graph from code repositories, documentation, and issue backlogs. Each domain became a local graph, unified into a “graph of graphs.” The first day focused on technical scoping, deliberately limiting meetings. Manual note-taking was forbidden; instead, the team relied on Gemini transcriptions. During each 30–45 minute discussion, at least one person had an active Claude session with the knowledge graph open. Claude used the graph and conversation summaries to produce scope documents. Four scopes were validated by day’s end, compared to the usual cadence of one every two weeks in the classic async process.

On day two, each scope was manually broken into macro-tasks – a deliberate half-hour human step to retain subject mastery. Rules favoured functional isolation and avoided micro-tasks. Convergent patterns were codified as reusable skills (knowledge or workflows). The 13 resulting macro-tasks were defined using a hybrid approach: a human and Claude wrote definitions separately, then reconciled them. After approval in Google Docs, each definition was fed into OpenSpec, which generated a proposal, design document, technical specs, and implementation task list. By day’s end, 12 of 13 were merged (the last required extra cycles spilling into day three).

Days three and four were for implementation. Each task opened a fresh Claude session connected to the knowledge graph and relevant skills, then applied changes. Both step-by-step supervision and final PR review strategies worked, depending on personal style. A Slack canvas synchronized the pipeline. By day four, 12 implementations were validated in the development environment.

Day five brought peer review and staging deployment. PRs were examined one by one in dependency order; the owner explained changes file by file and gave a local demo. After team approval, Claude did a final check against the original specification. Production deployment waited until Monday, when 10 of 13 tasks went live – no Friday releases.

The experiment claimed a “2× acceleration factor”: three developers in one week delivered what normally takes three weeks. Doctolib acknowledged biases: external dependencies were pre-removed, and the seniority of the team meant decisions didn’t need escalation. Positively, reviews weren’t a bottleneck – 23 PRs stayed open an average of under 28 hours. Synchronous work also accelerated learning; one team member hadn’t touched the codebase in nine months and picked it up faster than in traditional sprints.

Yet the trial surfaced new challenges. “Nothing happened automatically,” the team noted; every transition from summary to scope to spec required a human trigger. The setup lacked integration and proactivity, leading to repetitive orchestrating prompts with the same context. Token consumption hit 1.719 million, costing $1,008, and the $300 knowledge graph isn’t reusable. Doctolib didn’t rightsize models, and there’s a broader risk of locking development workflows into agentic infrastructures.

Scalability remains open: maintaining team synchronization when multiple delivery streams compete for the same resources is difficult. Mental load from context switching was high (seven subjects covered); focusing on one or two major themes might improve both velocity and well-being. Maintenance was already an issue by week’s end – the knowledge graph was partly obsolete, and skills based on a prior codebase version had to be rewritten mid-experiment. No shared rules file or change propagation process existed.

For the next iteration, Doctolib plans a one-month window with a full team and two parallel delivery streams. Daily stand-ups would shift to end-of-day, and each stream would concentrate on two major themes per week to reduce context switching and detect overlaps earlier. Weeks would start on Tuesday to allow end-of-week deployments. On the agent side, per-repository graphs will be continuously updated, skills will encode team best practices, and pipeline transitions will be automated via a sandboxed remote agent with model selection integrated.

Le plus difficile quand on travaille à l’échelle avec l’IA, c’est de concevoir des processus humains pour garder le contrôle sur ce qu’elle produit.

Doctolib conclut ainsi son compte rendu d’une expérience menée la semaine du 18 mai 2026. L’idée générale : plutôt que de calquer des agents sur les méthodes de travail des développeurs, adapter ces méthodes, sur un mode de collaboration synchrone. Trois personnes (senior engineer, staff engineer, engineering manager) y ont participé, réunies dans une salle virtuelle. Leurs écrans étaient partagés en continu.

GraphRAG et Gemini pour le cadrage technique

En amont de l’expérience, Doctolib avait construit un graphe de connaissances à partir de dépôts de code, de documentation et de backlogs d’issues. Chaque domaine avait été transformé en un graphe local, l’ensemble étant combiné en un graphe de graphes.

Le cadrage technique a occupé la première journée. L’objectif était d’organiser le moins de réunions possible. La prise de notes manuelle était interdite : on devait faire confiance aux retranscriptions de Gemini. Pendant chaque discussion (30 à 45 minutes par sujet selon la complexité), au moins une personne avait une session Claude active, avec le graphe de connaissances ouvert. Si besoin, on pouvait inviter une personne externe pour 10 minutes de Q&A. Claude utilisait le graphe et le résumé des discussions pour effectuer le scoping.

À la fin de la journée, 4 cadrages étaient validés. À comparer à la cadence d’un toutes les 2 semaines dans le processus asynchrone classique.

Une approche hybride pour l’écriture des définitions

Le deuxième jour, chaque cadrage a été divisé en macro-tâches. Un travail d’une demi-heure réalisé par l’humain – choix volontaire pour s’assurer de la maîtrise du sujet. Principales règles : éviter les micro-tâches, maximiser l’isolation fonctionnelle et ne pas rejeter les dépendances.

Une fois ce mapping effectué, les principaux patterns convergents ont été codifiés en skills réutilisables. Soit sous forme de connaissances, soit sous forme de workflows.

L’étape suivante a consisté à se répartir les 13 macro-tâches pour en rédiger les définitions. L’approche hybride (écriture par un humain et par Claude, puis réconciliation) a produit les résultats les plus intéressants.

Une fois validées (collaboration Google Docs), les définitions passaient à la moulinette OpenSpec. Il en résultait une proposition, un document de conception, des spécifications techniques et une liste de tâches d’implémentation. Autant d’artefacts à réviser puis à fusionner. À la fin de la journée, 12 sur 13 l’étaient effectivement (le dernier a exigé une boucle qui a débordé sur J3).

10 tâches sur 13 finalement passées en prod

Les troisième et quatrième jours furent dédiés à l’implémentation. Chacun ouvrait une nouvelle session Claude par tâche, associait le graphe de connaissances et les skills pertinentes, puis exécutait l’apply. Entre la supervision action par action et la revue finale du PR, les deux stratégies ont fonctionné, expliqué Doctolib. Le choix était une question de style personnel…

Un canevas Slack a permis de synchroniser le travail au long du pipeline. À la fin du quatrième jour, 12 implémentations sur 13 étaient validées dans l’environnement de développement.

Revue par les pairs et déploiement en staging étaient au menu du 5e jour. Sujet par sujet, dans l’ordre des dépendances, chaque PR a été examiné. L’owner expliquait les changements fichier par fichier et exécute une démo locale. Après approbation de l’équipe, Claude réalisait une dernière vérification à partir de la spécification originale.

Pas de déploiement en prod… car c’était vendredi. Le lundi suivant 10 des 13 tâches ont finalement passé ce cap.

3 semaines de travail au lieu de 6

Le backlog retenu équivalait à 6 semaines de travail. Doctolib revendique donc un « facteur d’accélération de 2x » (3 développeurs pendant 1 semaine = 3 semaines de travail). L’expérience n’a pas été exempte de biais, admet-il. Il avait, entre autres, écarté au préalable les dépendances externes. L’équipe disposait par ailleurs d’assez de séniorité pour prendre des décisions sans escalade.

Parmi les enseignements positifs, le fait que les revues n’ont pas constitué un goulet d’étranglement. Les 23 PR générés sont, en moyenne, restés ouverts un peu moins de 28 heures. Le travail synchrone a aidé. Il a aussi favorisé la maîtrise au sein de l’équipe – dont un membre n’avait plus touché à la codebase de l’entreprise depuis 9 mois. L’apprentissage, affirme Doctolib, s’est fait à une cadence que les sprints traditionnels ne permettent pas.

Automatisation, coût, maintenance… D’autres types de défis

L’expérience a effacé certains obstacles mais en a engendré d’autres. Par exemple, « rien ne s’est passé automatiquement », pour reprendre les mots de Doctolib. Chaque transition (du résumé au cadrage, de la tâche à la spec, etc.) dépendait d’une action humaine. Constat : « Notre setup manquait partout d’intégration et de proactivité. […] On a perdu un temps important à répéter les mêmes prompts d’orchestration avec le même contexte ».

Demeure aussi la question des coûts. L’expérience a consommé 1,719 millions de tokens, pour une facture de 1008 $. Doctolib reconnaît ne pas avoir pratiqué le rightsizing (il a utilisé les modèles par défaut). Son graphe de connaissances, qui lui a coûté 300 $, n’est pas réutilisable. Une réflexion apparaît d’autant plus prioritaire qu’il existe, à l’échelle, un risque de verrouillage des workflows de développement dans des infrastructures agentiques.

Le passage à l’échelle présente un autre défi : maintenir la synchronisation d’équipe. Ici, l’autorité décisionnelle était concentrée, le product manager était joignable et des collaborateurs externes pouvaient être invités. Répliquer cela sur de multiples flux de delivery exploitant simultanément les mêmes ressources est une autre paire de manches.

Doctolib évoque aussi la charge mentale liée au changement de contexte. L’expérience a couvert 7 sujets. Un backlog centré sur un ou deux thèmes majeurs aurait probablement accru la vélocité… et le bien-être.

La maintenance pose également problème. À la fin de la semaine, le graphe de connaissances était déjà partiellement obsolète. Dans le même esprit, les skills, fondées sur une version précédente de la codebase, ont dû être réécrites au milieu de l’expérience. Il n’y avait par ailleurs pas de fichier de règles partagé et pas de processus de propagation des changements.

Des pistes pour une prochaine expérience

Pour la prochaine itération, Doctolib envisage une fenêtre d’un mois, avec une équipe complète et deux flux de delivery parallèles. Il pense repositionner la réunion du matin en fin de journée et focaliser chaque flux sur deux thèmes majeurs par semaine. Autant pour limiter le changement de contexte que pour détecter les chevauchements plus en amont. La semaine commencerait le mardi, permettant le déploiement en fin de semaine plutôt que le lundi suivant.

Sur la partie agent experience, Doctolib prévoit un graphe par repo, mis à jour en continu. Il compte produire des skills encodant les bonnes pratiques de ses équipes. Et automatiser les transitions de pipeline à l’appui d’un agent distant en sandbox. Tout en intégrant une sélection des modèles.

Illustration générée par IA

The post L’IA agentique change les méthodes de travail : Doctolib l’expérimente auprès de ses développeurs appeared first on Silicon.fr.