Le chiffre circule depuis quelques semaines : chez Alan, plus de 280 pull requests ont été fusionnées en un trimestre par des collaborateurs qui n'avaient jamais écrit une ligne de code. Un an plus tôt, le même compteur affichait zéro.
Le contexte compte, parce qu'il n'est pas généralisable tel quel : une équipe d'ingénierie de 150 personnes, un million de membres assurés, un monorepo, la certification ISO 27001, et surtout une culture où toutes les décisions se prennent à l'écrit, dans des issues GitHub - techniques comme métier. Alexandre Gerlic le formule bien : c'est le mode de fonctionnement d'entreprise le plus proche de l'open source qu'il connaisse.
Cette dernière caractéristique n'est pas un détail culturel. C'est ce qui a rendu la suite possible.
Le pari de départ : surtout pas un outil à part
Quand le projet démarre, à l'été 2025, le marché déborde d'outils promettant de faire coder les non-développeurs. Alan les écarte tous, et le raisonnement mérite d'être cité :
Si on commence à utiliser des outils différents, on va recréer des silos, et c'est exactement la trajectoire vers laquelle je n'ai pas envie qu'on aille.
Décision : les non-ingénieurs utilisent exactement les mêmes outils que les ingénieurs. Même environnement de développement, mêmes linters, même chaîne d'intégration, mêmes pull requests, même revue. Deux bénéfices, et le second est le plus important : on ne fabrique pas de silo artificiel comme l'avaient fait les vagues no-code précédentes, et on s'appuie sur une chaîne de livraison dont on sait déjà qu'elle tient.
C'est le point qu'on retiendrait si on ne devait en retenir qu'un. Ouvrir le code à tout le monde n'a pas consisté à baisser les exigences pour les nouveaux venus. Cela a consisté à les faire entrer dans le dispositif existant, sans porte dérobée.
Ce qui a bloqué n'était pas ce qu'on croyait
Premier apprentissage, et il est contre-intuitif : la génération de code n'a pas été le problème. Dès que le prompt était à peu près correct, les modèles de l'époque produisaient du code qui faisait le travail.
Ce qui a coincé, c'est tout ce qu'il y a autour. Qu'est-ce qu'une branche Git ? Comment savoir qu'on n'a pas créé un conflit qu'on ne saura pas résoudre ? Et surtout : comment savoir si ce qu'on demande est compliqué ? Une modification qui semble triviale du point de vue de l'expérience utilisateur peut impliquer un changement de modèle de données et une migration de base. Personne ne l'a jamais annoncé à un designer.
La réponse a été de borner. Front-end oui, sur l'application web comme sur l'app mobile ; back-end non ; base de données surtout pas. Et un critère explicite pour choisir le périmètre : la boucle de retour doit être visible. Sur le front, la personne modifie, la page se recharge, elle voit si le parcours qu'elle avait en tête fonctionne. C'est cette boucle-là qui permet à un non-développeur d'apprendre sans supervision permanente.
Résultat annexe assez frappant : le délai entre le début de l'expérimentation et la première mise en production par un non-développeur a été de 24 heures. Un ingénieur qui rejoint Alan livre sa première pull request dans la semaine. Il faut lire ce contraste correctement - la personne des opérations modifiait un outil interne qu'elle utilise tous les jours, dans un domaine qu'elle connaît par cœur, alors que l'ingénieur doit d'abord apprendre la maison. La question posée est bonne : entre l'expert du domaine qui ne connaît pas le code et l'expert du code qui ne connaît pas le domaine, qui livre le premier ?
L'ownership, seul vrai sujet de désaccord
Il n'y a pas eu de levée de boucliers côté ingénierie, mais un point a été discuté plus que les autres : si quelqu'un des opérations pousse une modification, qui est responsable quand elle casse en production ? Cette personne ne pourra pas la déboguer.
La réponse retenue est simple et transposable : un pairing avec un ingénieur, dont la revue de code engage. L'ownership reste au niveau de l'équipe, pas de l'auteur du commit. L'argument avancé est bon : design, PM et engineering discutaient déjà ensemble de la meilleure solution pour les membres avant que quiconque n'écrive du code ; ce qui change, c'est l'endroit où la conversation a lieu, pas qui en répond.
Le dispositif a tenu « dans 80 % du temps », et l'exception est intéressante : de temps en temps, quelqu'un ouvre une pull request sans pairing, en disant simplement « j'ai eu cette idée ». Challenging du point de vue de l'ownership, positif du point de vue de l'état d'esprit - et c'était précisément le but recherché. Plutôt que « j'ai vu ce bug, je vais faire un ticket », « j'ouvre l'éditeur et je regarde si c'est compliqué ».
Toutes les pull requests, y compris les corrections de fautes de frappe, ont continué à être relues par l'équipe d'ingénierie. Rien n'a été assoupli. C'est ce qui a permis d'ouvrir sans casser.
L'effet de bord que personne n'avait prévu
Deux anecdotes du récit valent mieux qu'un argumentaire.
La première : un designer refait entièrement le parcours de recueil des avis membres, en récupérant depuis Figma ce dont il avait besoin. Le VP Engineering, qui pensait la chose hors de portée, va voir à son bureau et constate que si. Il l'explique par une absence de plafond mental : le designer ne savait pas que c'était censé être difficile.
La seconde est plus instructive encore. Une personne lance un prompt pour une petite modification sur un outil interne jamais migré vers le design system maison - une de ces migrations achevées à 80 % qu'on ne finit jamais. L'agent, lisant les règles du dépôt, y trouve la consigne d'utiliser le design system à jour et de proposer la mise à niveau des composants obsolètes rencontrés en chemin. La pull request part avec la petite modification demandée et trois fichiers migrés.
Autrement dit : la contribution d'une non-développeuse a amélioré la qualité de la base de code, et fait avancer une migration dépriorisée depuis des mois. La règle du boy-scout - laisser le code plus propre qu'on ne l'a trouvé - que tout le monde connaît et que personne n'applique faute de temps, appliquée par quelqu'un qui n'a jamais eu l'occasion de prendre le mauvais pli.
Et l'effet se referme sur lui-même : les règles, les linters et l'outillage écrits pour fiabiliser les contributions des non-développeurs ont amélioré l'environnement de travail des développeurs. Les deux équipes internes - celle du programme et celle de l'environnement de développement - ont fini par converger.
Le goulot suivant est déjà là : la revue
C'est la partie la plus honnête du récit, et la plus utile à quiconque envisage la même chose. Le programme fonctionne, donc il produit des centaines de pull requests supplémentaires. En parallèle, les ingénieurs adoptent des outils agentiques qui multiplient eux aussi le nombre de pull requests. Les deux mouvements convergent au même endroit : la revue de code ne passe pas à l'échelle.
S'y ajoute une contrainte réglementaire - ISO 27001 impose de savoir comment un changement arrive en production - qui interdit d'y répondre en relâchant la vigilance.
La question que pose Alexandre Gerlic est plus dérangeante que le constat :
Au moment où tu fais la code review, tu as envie de te dire : est-ce que ce n'est pas déjà trop tard ? Pourquoi est-ce que le code généré n'est pas déjà bon ? Qu'est-ce qui manque ?
L'objectif qu'il formule est ambitieux et assumé comme incertain : faire en sorte que le système apprenne des retours donnés, pour que la même erreur ne soit corrigée qu'une fois. Non pas supprimer la revue, mais cesser de traiter comme une fatalité le fait qu'elle absorbe le gain de vitesse en amont.
Nous avions décrit le même mur sous un autre angle avec le taux de fusion des pull requests d'IA mesuré par LinearB et avec la « vibecoding fatigue » : quand la production accélère et que la validation reste calibrée pour un débit humain, c'est la validation qui devient le produit.
« Everything has code » : le prolongement inattendu
Le projet a produit un déplacement que personne n'avait mis dans le plan initial. Alan maintient aujourd'hui un dépôt de skills - un mélange de fichiers Markdown et de scripts - qui ne sert pas qu'à coder : préparation de réunions, coaching, reporting hebdomadaire. Et l'anecdote qui résume tout : une pull request sur l'un de ces skills a été relue et fusionnée par une personne de l'équipe RH.
C'est le passage de « everyone can build » à « everything has code ». Les manières de travailler de l'entreprise entrent dans un dépôt, passent par une revue, se versionnent. Une organisation qui prend déjà toutes ses décisions à l'écrit avait, sans le savoir, une longueur d'avance considérable : son contexte était déjà rédigé.
La discipline reste le facteur limitant
Il faut lire ce retour d'expérience à côté de ce qui se passe ailleurs, sinon on en tire la mauvaise leçon. Le mouvement est général : Ramp rapporte plus de 1 500 applications internes livrées en six semaines par plus de 800 contributeurs non-ingénieurs ; une enquête menée auprès de 200 RSSI d'entreprise estime que les personnes qui construisent des logiciels métier sont désormais 4 à 10 fois plus nombreuses que les développeurs professionnels dans les grandes organisations.
Et le revers est documenté aussi. Thoughtworks cite 25 % de code généré par IA présentant des vulnérabilités confirmées et une violation de sécurité sur cinq désormais liée à du code généré par IA ; Gartner parle de « surfaces d'attaque fantômes » créées par l'adoption d'outils et d'agents sans supervision centrale.
D'où la distinction que le blog d'Aha! propose entre vibe coding et PM coding, et qui n'est pas qu'un jeu de mots : « l'IA vous donne la capacité d'une équipe technique, pas le jugement d'un product leader ». Le premier part d'une solution parce qu'elle est devenue peu coûteuse à écrire ; le second part d'un besoin, définit ce que réussir veut dire, et ne construit qu'après.
Une équipe qui a fait tourner un atelier de ce type en tire cinq questions qu'aucun tutoriel de code n'enseigne, et qui sont exactement celles qu'Alan avait tranchées avant d'ouvrir les vannes :
- Faut-il construire ceci, ou est-ce que ça existe déjà ?
- Pour qui, et comment sait-on que son problème est bien celui qu'on croit ?
- Comment testera-t-on ce logiciel à mesure que les modèles changent ?
- Qui en est propriétaire après la mise en ligne, correctifs de sécurité et fin de vie compris ?
- Combien coûte sa maintenance, comparé à ce qu'il résout ?
La quatrième est celle qu'on saute, et c'est celle qu'Alan a traitée en premier.
Ce que Survol en fait
Ce retour d'expérience décrit, sans le nommer, l'étage sur lequel nous travaillons. Trois correspondances directes :
- Les règles plutôt que les outils. Chez Alan, ce sont les fichiers de règles du dépôt qui ont permis d'ouvrir la porte sans baisser la qualité - jusqu'à faire appliquer une migration oubliée. C'est exactement ce que font nos contraintes techniques d'organisation, injectées au début de chaque session, hiérarchisées et tracées quand un agent les conteste.
- Un propriétaire nommé, pas un auteur de commit. Chaque demande passe par une spécification validée, avec une décision produit attribuée. La question « qui répond de ce changement ? » a une réponse avant la mise en production, pas après l'incident.
- Le contexte est déjà écrit. L'avantage d'Alan, ce sont ses décisions rédigées. La plupart des entreprises ne les ont pas - c'est pour cela que Survol reconstitue la carte des fonctionnalités à partir des dépôts existants, avec un niveau de confiance, et transforme chaque zone d'ombre en décision produit ouverte plutôt qu'en supposition.
Sur le goulot de la revue, nous n'avons pas de réponse magique à proposer, et personne n'en a. Mais la direction indiquée par Alexandre Gerlic est la bonne : le progrès ne viendra pas de relire plus vite, il viendra de faire en sorte que la même remarque n'ait pas à être faite deux fois.
Sources
- If This Then Dev, « Et si n'importe qui dans l'entreprise pouvait proposer une pull request ? », entretien avec Alexandre Gerlic, VP Engineering d'Alan.
- Brian de Haaff, « Vibe coding vs. PM coding », Aha!.
- Geoff Smalling, « When everyone can build software, judgment matters more », Fast Company, 4 août 2026.
