Synthèse
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...
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.
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.
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).
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.
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.
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.
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.
Source originale
silicon.fr