Effectivement il faudrait prendre plus de temps sur la relecture. La difficulté est de le faire en un temps raisonnable par rapport au projet avec les ressources et compétences disponibles. On pourrait avoir une relecture en deux temps : une première pour fusionner sur la branche master pour permettre d’avancer sur des fonctionnalités interdépendantes, et une deuxième sur stable pour dire que le code est prêt à partir en production. Ça permettrait peut-être de combiner la nécessité d’avancer qui apparaît de temps en temps et les exigences en matière de qualité que l’on est en droit d’attendre de Duniter. Est-ce que tu penses qu’une branche stable permettrait de prendre le temps nécessaire pour une bonne relecture ?
Ça peut être dev et master aussi.
Si je comprends bien, le processus serait :
- MR vers master
- relecture pouvant être rapide si une autre MR dépend de celle-ci
- merger dans master
- re-relecture pouvant donner lieu à une MR corrective dans master
- Pour ne pas oublier quelles MR doivent être re-relues, et pour ne pas re-relire celles qui l’ont déjà été suffisamment, il faudrait que chaque relecture rapide soit notée dans une todo-list, dans je-ne-sais quel outil de GitLab ou bien dans un fichier du dépôt (qui serait vérifié avant chaque rebasage dans stable).
- merger ou rebaser dans stable
Oui, dev et master conviennent aussi comme noms. C’est bien comme ça que j’imaginais cet éventuel nouveau processus. Pour savoir quelles MR ont été relues avec attention par un tiers n’ayant pas participé à l’écriture, on pourrait tout simplement avoir un tag #audited ou #reviewed dans la MR d’origine.
Si on avait les moyens financiers, on pourrait même déléguer cette tâche à un acteur tiers spécialisé dans l’audit de code.
Vu ce qui se passe en ce moment, je me dis que l’important n’est pas tant master, stable ou dev, mais plutôt les branches de réseau, en particulier network/g1. Effectivement, il faudrait que chaque commit intégré dans cette branche de réseau ait reçu plusieurs #audited de telle sorte à ce que les forgerons à qui on demande d’installer une version de Duniter puissent vérifier que toutes les MR aient reçu une relecture.
Je recommande plutôt de ne garder que la branche master et une branche par release.
Plutôt qu’une autre branche, il est possible de coder un petit script qui génère un tableau avec toutes les MR mergés entre deux releases, et indique le nombre de review avec une coche verte ou une croix rouge.
Ca pourrait être un script qui s’exécute en première étape du processus de release et qui fait échouer le processus de release si toutes les MR n’ont pas un certain label par exemple. La personne qui fait la release reste libre d’ajouter manuellement le label manquant à chaque MR, mais ça oblige à opt-in manuellement et donc à ce demander; est-ce que cette MR à été suffisamment auditée?
Je suis toujours d’accord avec ça
Toujours d’accord avec ça aussi
C’est particulièrement vrai en ce moment avec les MR faites à la pelle avec des IA.
Je vois quand même un problème à merger avant relecture, ça complexifie le travail d’intégration. Si une relecture trouve des choses à redire, il faudra faire les correctifs par dessus toutes les autres MR qui auront été mergées entre temps.
Aujourd’hui je suis un peu peiné de voir des merge requests fusionnées avec uniquement l’approbation de leur auteur comme :
- duniter !386 dont on n’a discuté que rapidement pendant le hackathon
- squid !35 qui est juste un empilement de truc dégueulasses (on parle d’un script python hardcodé dans un script bash qui prend en sortie des données traitées en amont, je sais même plus quel est le flux de la données)
Ça me démotive de voir des issues traitées à la pelle sans tellement d’attention à la codebase. J’ai peur qu’on se retrouve plus tard avec des problèmes de maintenabilité.
Pour moi, dire qu’on merge tout parce que ça marche à 90% et qu’on traitera les problèmes plus tard, c’est la définition de la dette technique, et ce n’est pas quelque chose que je souhaite. Je ne pense pas que l’IA pourra nous aider à éponger de la dette technique.
Je pense le contraire, je vais d’ailleurs commencer mes prototypes d’éponge à dette dès la semaine prochaine pour le boulot.
Nous verrons bien si je me fourvoie ou pas. Si j’aboutis j’orienterai alors la force de frappe vers Duniter/Cesium afin de contrebalancer l’AI slop apportée par Claude/Codex.
Oui, je suis d’accord sur ce dernier point. Les agents IA ont tellement progressés… Et ils hallucinent le moins en moins.
Je les utilisent souvent pour du refactoring massif.
Cependant je comprends aussi @HugoTrentesaux : pour l’avoir vécu les semaines passées sur Cesium2, c’est assez frustrant de ne pas pouvoir tout relire sur des MR, générée par IA, qui sont mergées très vite.
Mais malgré tout les choses ont ainsi avancées plus vite, et j’ai pu ensuite reprendre/simplifier/épurer des fonctions ou des templates (mal) codées par des IA (en utilisant des IA pour le faire), donc en épongeant une partie de la dette technique, sans tout casser.
C’est une nouvelle manière de gérer les projets, auxquels il faut sans doute nous adapter..car les gains sont plus importants que les problèmes apportés (il me semble, mais ça reste a démontrer).
Du coup ça m’intéresse que tu jettes un oeil sur ce que je prépare ici: Axiom's bot / duniter-automation · GitLab
Pas finis, mais il y a les specs dans le dossier docs.
Arf, je vois que tu fais du n8n. 
On en fait aussi pour le boulot.
Mais finalement on a qualifié que le faire en code java était beaucoup plus simple et efficace (avec Spring boot) et surtout moins risqué en terme de licence (non libre !). Mais bon en fait quand même un peu, quand ça vaut pas le coup de coder 3 lignes.
Je regarderai par curiosité, la semaine prochaine.
Je suis sensible aux remarques de Hugo sur la dette technique, et suis d’accord sur le fait que le rythme tenu ces dernières semaines n’est pas souhaitable à plus long terme.
Par contre il était indispensable pour donner le coup de collier permettant de réaliser les opérations du 08/03 sans faire d’énormes sacrifices personnels pour y arriver.
Désormais l’urgence est passée (même pour Cesium), il est temps de reprendre un rythme plus humain. D’ailleurs je suis fatigué de ces derniers mois, @elois a évoqué un repos bien mérité et je dois avouer mon soulagement en lisant ses lignes : “enfin”.
Quant à l’IA, on n’en est qu’au début.
Je ne fais pas du n8n, tout est codé par Claude, les workflow as code, et leur gestion via le MCP n8n. C’est ce qui était le plus simple pour moi (une nuit de travail pour en arrivé là, partant d’une feuille blanche).
Mais recoder le workflow dans un autre language revient au même, peu importe, tous revient globalement au même.
Je suis d’accords pour le rythme trop soutenu, mais pour moi automatiser la production et la chaine de valeur est totalement possible, et même souhaitable. Je pense que les développeurs n’auront bientôt plus qu’une place de validation de ticket et validations des tests et des MR.
Automatiser le support permettrait aux utilisateur d’avoir des réponses rapidement, des tickets associé lorsque c’est pertinent et nécessaire, sinon d’avoir une réponse basé sur nos documentation et instruction, et d’alerter/demander aux dev lorsqu’il est nécessaire pour le modèle d’avoir des précision et de trancher des choses.
Pour info et pour ceux qui sont frileux avec les LLM propriétaire, axiom dispose d’un Mac Studio avec 192Go de RAM permettant de faire tourner sans problème des modèles 230B.
Pour le moment on a surtout testé des modèles ablitarated pour s’amuser (et dieu sait que c’est amusant), mais il reste à tester des qwen 3.5 ou autre orienté code pour voir à quel point c’est moins bien que Claude.
Ah ok. Pour ma part je ne sous-traite pas (a une IA ou a un dev) quelque chose que je ne maîtrise pas moi même. C’est une règle d’or qui me vient de celui m’a formé, et que je trouve particulièrement utile avec les agents IA.
Cela permet un regard critique sur le qualité du code, et aussi de conserver l’expertise finale, en cas de problème d’architecture (pb de performance, bug compliqué, etc).
C’est ma vision des agents IA : ce sont des bons développeurs junior, qu’il faut donc absolument encadrer strictement (via les rules notamment, qui sont actualisés a chaque erreur de l’IA) sous peine d’une dette technique énorme, et une solution peu fiable.
C’est par exemple comme cela que fait le créateur de Claude Code : Claude Code tout, mais l’humain review tout et fait changer ou compléter les rules a chaque erreur.
Par exemple, côté back nous codons maintenant 90% ou 95% via agents IA, sur les applications existantes, et le reste est réservé au cas plus complexes. Nous arriverons a 100% sans dette technique, sur les nouvelles applications, d’ici peu de temps.
Sur Cesium2, je vais effectivement avoir pas mal de boulot pour reprendre une partie du code, mais c’est ok car c’est ce que nous avions convenu ensemble, pour la maintenance du repo. Et les circonstances étaient particulières.
A suivre…
Voici le source :
https://x.com/i/status/2007179832300581177
Un gars a suivre à mon avis.
Je comprends le point de vue, pour ma part, j’ai de plus en plus de mal à considérer les modèles frontiers comme des développeurs Junior, je trouve que c’est mettre beaucoup de pression sur les développeurs Juniors !
… Ou alors il est constamment sous amphetamine ton dev !
Quand on voit la qualité du code produit, la capacité d’analyse, les réflexions UX, ça se rapproche quand même bien plus d’un jeune Senior je trouve.
D’expérience, je n’ai aucun problème à maintenir une stack dont je ne maitrise initialement pas la techno, entièrement vibe codé. Je parle de très gros projets, bien plus volumineux que ce qu’on fait ici.
Mon rôle est devenu plus celui d’un architecte / debugger / analyste, qui valide des architectures et des pratiques, quelque soit le langage ou la stack utilisé.
Oui je comprends ton point de vue. L’enjeu est de passer l’IA de niveau junior ++ (certes avec haute dispo, etc. mais aussi générateur de dette technique) à un niveau senior où les erreurs sont rares, et la qualité du code irréprochable (pas pu très peu de reprise).
Disons qu’une IA laissée libre de toutes règles, aura une approche plus naïve (car son contexte est limité) alors qu’une IA encadrée par des règles (=contexte forcé en quelques sortes) saura utiliser toutes les subtilités de l’architecture mise en place. J’ai bien dans vos MR Cesium2 par exemple qu’elle manquait clairement de cadrage. Bref.
On est bien d’accord. Mais pour debugger/analyser tu es d’accord qu’il faut maîtriser un minimum la techno ?
Mais bon, je crois que nos différences de point de vue sont d’avantage philosophique. Tu es sûrement plus pressé que moi. Donc pour résumer, je dirais “rien de sert de courir, il faut partir a point”
La vitesse de réalisation ne m’impressionne pas trop, mais d’avantage la qualité et le but atteint.
Le problème, c’est qu’il y a trop peu d’humains suffisamment à l’aise pour faire une review humaine de certaines de mes MR. Je dirais qu’il n’y à même souvent que @HugoTrentesaux et que ses disponibilités pour review sont trop éparses, et ça m’obligerait à conserver trop de branches et MR en parallèle.
Exemple d’un commentaire de cgeek dans la MR duniter !363 :
Je ne sais pas juger cette MR, soit quelqu’un d’autre veut donner son avis, soit tu merges directement.
Même au boulot, avec des devs payés à plein temps, on a ce problème. Ce qu’on a fait à mon travail, c’est qu’on a mis en place un bot AI qui peut review et approuver les PR : il s’agit de coderabbit.
De plus, on fait des reviews locales avec plusieurs modèles, et je fais de même avec mes MR Duniter. Elles sont toutes auditées par 3 modèles d’IA différents dans des chats vierges, jusqu’à ce qu’aucun d’entre eux ne trouve plus rien.
Je review aussi toutes mes MR moi-même, mais seulement après les reviews des IA, et je n’ai pas le biais de “relire mon propre code” car je n’écris plus de code manuellement depuis plusieurs mois déjà.
Je sais que c’est un changement de paradigme qui peut faire peur, mais au boulot tout le monde le fait pour de vrais projets en prod, qui pour certains comme Moonbeam sécurisent des centaines de millions de dollars. On a créé des process adaptés pour que ce soit moins risqué, et en pratique on ship moins de bugs qu’avant, lorsque le code était écrit et relu uniquement par des humains.
Les vraies clés pour que les revues par IA soient fiables sont :
- Avant les changements : planifier avec l’IA et s’assurer qu’on comprend parfaitement le plan.
- Utiliser plusieurs modèles différents et ne leur donner aucun contexte autre que les git diff. Toute description des changements peut faire croire aux IA qu’on a vérifié telle assumption alors que non.
- Faire review aux autres modèles les findings de chacun pour ne garder et traiter que les findings légitimes.
- Utiliser aussi des modèles de plus petite taille : j’ai eu un cas au boulot où Opus 4.6 et GPT 5.4 ont approuvé tous les deux des git diff sans aucun finding ; un plus petit modèle a trouvé 2 findings légitimes que Opus 4.6 et GPT 5.4 ont confirmés comme légitimes.
- Lorsque toutes les reviews IA ne trouvent plus rien, faire une revue humaine des scénarios de test et une exécution locale des scénarios de test.
Mon plan, dans les temps à venir, c’est d’ajouter beaucoup plus de tests end-to-end à Duniter. Mais j’ai d’abord besoin de simplifier la stack des tests end-to-end pour ça, en passant à du TypeScript, pour plein de raisons que je détaillerai dans un ticket.
Au fond, je suis d’accord avec @kimamila : ne déléguer à l’IA que ce que vous comprenez. En tant que développeurs, notre rôle évolue : on n’écrit plus de code, mais on doit toujours tout comprendre.
C’est un peu comme quand on est passé du calcul mental à la calculatrice. Ça ne fait plus aucun sens de continuer à faire du calcul mental à l’ère des calculatrices, mais on doit toujours comprendre les formules qu’on saisit dans notre calculette.