Quand l’IA écrit le code, que font les développeurs ? Adrien Maret

À quoi ressemble le SDLC avant l’IA générative

Écouter à 02:50

Dans ce passage, Adrien décrit le SDLC comme un processus industriel qui enchaîne conception, build, QA, déploiement puis exploitation. Il explique que les étapes n’ont pas vraiment changé, mais que leur exécution a évolué, et rappelle qu’un logiciel continue de vivre après sa mise en production. Terry relance ensuite sur ce que l’IA générative compresse dans ce cycle et sur les frictions que cela déplace.

Adrien: Alors le cycle de développement logiciel, ou SDLC pour les intimes, c'est un processus en fait, c'est un processus industriel. Et donc comme tous les processus industriels, on a un certain nombre d'étapes, et si on respecte ces étapes correctement, à la fin on a un résultat. Et donc là le résultat c'est un logiciel qui fonctionne, et qu'on va pouvoir maintenir dans le temps. Donc avant, après le logiciel, pour moi les étapes elles n'ont pas vraiment changé. Ce qui a changé c'est la manière dont on va exécuter ces étapes, mais on reste... 40 ans, même 50 ans qu'on a ce cycle. On commence toujours en amont du cycle par des étapes de conception. Après, on pourra parler un peu du cycle étendu parce qu'avant la conception, on peut avoir par exemple la captation des besoins, la compréhension des utilisateurs, etc. Tout ce qui rentre plus dans la mouvance product. Mais vraiment sur le cycle du logiciel en lui-même, donc on a de la conception, donc atelier de cadrage, cahier des charges techniques, fonctionnels, tout ce qui est en amont. Ensuite, on va avoir des étapes de build, donc de construction où on va faire intervenir plusieurs types de profils on a du design en amont pour faire par exemple des maquettes ensuite on va avoir plutôt des profils développeurs pour faire le front-end le back-end, tout le dur les tests, etc. Ensuite, après ces étapes de build on va avoir des premières étapes de qualité donc QA, qualité assurance, où on va avoir des gens qui sont spécialisés en testing, qui vont pouvoir tester le logiciel un peu sous toutes ses coutures, pour vérifier qu'il réagit bien avec les cas à la marge, parce que les développeurs sont assez feignants par défaut, ils font quand ça marche avec le premier cas, ok, mais bon, si on met un peu n'importe quoi dans les champs, etc., on tombe sur des bugs. Une fois que le logiciel passe ses étapes de qualité, il est déployable, donc avant de le déployer, il faut provisionner une infrastructure, donc créer des serveurs, Aujourd'hui, avec du Terraform, des technologies d'infrastructure Ascode, ou pas d'ailleurs, aujourd'hui avec Claude Code, c'est aussi très facile d'instrumentaliser des bons vieux serveurs en SSH. Et puis ensuite, il faut déployer, donc livrer la dernière version sur cette infrastructure. Et puis après le déploiement, c'est vrai que là, parfois on peut imaginer qu'on sort du cycle, mais en fait, un logiciel, ce n'est pas quelque chose qui se crée, qui se déploie et qui s'oublie. C'est un patrimoine qu'il faut faire vivre, qu'il faut faire évoluer, dont il faut prendre soin, un peu comme un immeuble en fait, ou un appartement. Si on vit dans un appartement pendant 10 ans sans jamais faire des travaux de réfection, de la peinture, des choses comme ça, au bout de 10 ans, il est perdu de la valeur. Donc le logiciel, c'est pareil. Le logiciel, il continue à vivre après le déploiement. Et donc dans le cycle, pour moi, il faut aussi ajouter toute la phase d'exploitation, le run en anglais. Donc c'est mettre à jour les dépendances. récupérer les feedbacks des utilisateurs, les retours des utilisateurs pour les incorporer dans le logiciel, réparer les bugs et toutes ces choses-là.

Terry: Très clair. Donc tu disais, effectivement, avec l'IA générative, il y a toujours ce process, mais c'est juste des phases qui ont été comprimées. Donc quelles sont les phases qui ont été comprimées versus qu'est-ce que ça met ? Parce que de manière assez simple, on peut dire, évidemment, c'est le code, la partie build, du coup, boum, c'est comprimé. Mais du coup, ça implique pas mal de choses derrière sur là où il y a aussi de la friction qui se déporte par rapport à la compression de cette phase-là. Quelles sont les évolutions majeures qu'apporte l'IA générative dans ce processus de développement logiciel ?

Comment l’IA générative compresse l’écriture de code et crée de nouveaux goulots d’étranglement

Écouter à 06:12

Adrien explique que l’IA générative a surtout compressé l’écriture du code et des tests, parce que les LLM et les agents le font plus vite que les humains. Il décrit ensuite les goulots d’étranglement que cette accélération crée en amont sur le produit et le design, puis en aval chez les QA, alors que le déploiement reste pour l’instant moins touché. Terry recentre aussi l’échange sur la valeur apportée aux utilisateurs et interroge la manière dont une startup AI native peut éviter l’écart entre une production de code beaucoup plus rapide et des outcomes qui progressent peu.

Adrien: Alors, comme tu l'as dit, le truc, l'éléphant dans le couloir, c'est vraiment le code. Parce qu'avant, l'immense majorité, je n'ai pas les pourcentages en tête, mais l'immense majorité du travail et du coût du logiciel étaient... sur le poste de développement, que ce soit pour le build initial ou que ce soit pour la phase de maintenance, TMA, MCO, etc. Et donc aujourd'hui, ce qui se passe, c'est que cette phase de développement pure, bon, je n'ai pas détaillé la phase de développement, mais dans une phase de développement, on a aussi des étapes. Il y a les ateliers d'architecture, il y a l'écriture du code, il y a l'écriture des tests, il y a la review par les pairs, il y a plein d'étapes. Mais l'étape qui a été compressée, c'est uniquement la phase d'écriture de code et de test. En fait, c'est la phase où on... crache des lignes de code. Pourquoi ? Parce que les LLM et les agents, ils le font beaucoup plus vite que nous. Et du coup, ce qui est intéressant, c'est de voir que ce temps-là, il va créer le fait qu'à ce niveau-là du cycle, on ait une accélération, ça va créer des goulots d'étranglement un peu partout dans le cycle. Parce que c'était des postes qui, avant, en amont et en aval de la phase de build, fonctionnaient à une certaine vitesse, ou avaient en tout cas une certaine capacité d'équipe. Je ne sais pas, on disait 1 PO pour 6 devs. un UX designer pour une équipe de 6 devs, des choses comme ça, aujourd'hui, c'est des chiffres qui ne tiennent plus du tout. Aujourd'hui, on a des goulots d'étranglement qui se forment en amont, sur la partie produit, les gens qui préparent les spécifications, toute la partie conception. Ils ont besoin de produire beaucoup plus de nouvelles fonctionnalités, de collecter plus rapidement les besoins utilisateurs, les feedbacks, de réfléchir. comment intégrer ces fonctionnalités dans le produit, comment mettre les bonnes métriques, à quel endroit, enfin bref. Beaucoup plus de boulot, sauf qu'ils ne sont pas beaucoup plus. Il y en a toujours une personne pour 6 devs, disons. Pareil pour la phase de design. Donc pareil, il faut bien concevoir tous ces écrans avant que les devs les implémentent. Pour les phases après les développeurs, c'est pareil, les QA qui testent à la main, ils sont aussi surchargés. Et ceux qui ne sont pas encore trop surchargés, c'est ceux qui déploient. parce que pour l'instant, finalement, il y a beaucoup de choses qui sont automatiques dans les déploiements, continus, etc. Et puis, il n'y a pas non plus une nouvelle application qui doit être déployée par semaine. On reste plutôt sur un modèle où on a tout un tas d'applications plus ou moins legacy, donc déjà existantes, qui sont accélérées. Donc, la vitesse de production de fonctionnalités sur ces applications est accélérée, mais on n'a pas encore accéléré le déploiement de nouvelles applications sur un très grand nombre de cas d'usage. D'ailleurs, il y a des chiffres qui illustrent très bien Cette disparité entre les accélérations sur les endroits de cycles de développement logiciels, c'est que les développeurs, c'est une étude qui est sortie en mai, il me semble, et la production de code est 17 fois plus rapide. C'est complètement stratosphérique. 17 fois, tout le monde rêverait d'avoir ce genre de bénéfice. Sauf que la livraison de fonctionnalités en production, elle, ça a augmenté que de 1,3%. Donc 17 fois d'un côté, les développeurs, sur le build du code, et par contre la... la livraison de features en production, ce qui compte finalement, parce que la fin du jeu du jour c'est ce qui compte, livrer de la valeur aux utilisateurs, là c'est que 1,3%. Donc on se dit, elle est où cette différence ? En fait elle est sur tous ces autres postes du cycle de développement logiciel qui n'ont pas été augmentés de manière aussi importante que la partie de création de code.

Terry: Je dirais même plus que fonctionnalité, c'est la valeur. Potentiellement, ça ne se traduit pas en nombre de fonctionnalités, la valeur que tu apportes à tes users. Après, c'est là où la démarche produit toute son importance. Du coup, assez curieux de comprendre vous, sur votre projet là, en tant que startup AI native, comment est-ce que vous faites en sorte de capitaliser au max et d'éviter ce delta entre x17 versus 1, quelque chose en termes d'outcome pour les users ? Quels sont un peu vos modes de fonctionnement ?

Comment Maleus construit sa plateforme avec moins d’ingénieurs

Écouter à 10:05

Adrien explique comment, au sein de Maleus, une petite équipe de six ingénieurs travaille de façon très agile, avec peu de place pour l’UX design et une génération directe du front-end. Il développe aussi l’idée que les maquettes type Figma pourraient progressivement disparaître à mesure que produire des variations de front-end devient plus rapide. La discussion glisse ensuite vers le métier de développeur, la place croissante des phases de conception et de review, et la question posée par Terry sur ce qui peut être laissé à des agents de code.

Adrien: Alors déjà sur une startup où on n'est que 6 ingénieurs à travailler, forcément c'est pas du tout les mêmes enjeux que sur une boîte où il y a plusieurs équipes, des gros plateaux, ce genre de choses, donc on est beaucoup plus agile. Typiquement... On a un UX designer, mais qui est là à mi-temps, donc il nous aide après coup à prendre du recul sur ce qu'on a fait et faire en sorte qu'on puisse redesigner l'expérience utilisateur. Mais aujourd'hui, il n'y a déjà pas d'UX designer. La partie maquette, en fait, c'est qu'on génère directement le code front-end et ensuite on fait des reviews entre nous, on se dit « ah bah oui, c'est bien, c'est pas bien » . On montre même au client, donc on est très rapide à déployer dans nos environnements de preview ou de staging pour ensuite montrer au client et prendre leurs avis en live.

Terry: Donc vous faites une plateforme qui permet à des profils non techniques de construire des logiciels de bout en bout. C'est ça. Alors là,

Adrien: je parlais de la manière dont nous, on travaille pour construire cette plateforme, pour construire Maleus. Dans Maleus, c'est un peu différent dans le sens...

Terry: Après, on pourra aller dans Maleus, mais c'est juste pour bien recontactualiser le produit dont on parle là, à quoi il sert.

Adrien: C'est ça, ouais. Donc finalement, sur cette partie écran, maquette, il y a plein d'équipes, c'est un poste qui est comprimé assez rapidement si on n'a pas un UX designer à plein temps. Mais du coup, nous, en fait, on génère directement du front-end. D'ailleurs, aujourd'hui, personnellement, je pense que les maquettes type Figma, c'est quelque chose qui progressivement va disparaître versus ce qu'on peut faire aujourd'hui en générant directement du code front-end. Pourquoi on a des maquettes Figma ? Parce qu'avant, écrire un front-end complet et le décliner en trois versions, ça prenait beaucoup trop de temps, c'était beaucoup trop cher en termes de coût développeur. Donc, on avait plutôt un UX designer qui faisait avec Figma, mais ça prend quand même du temps. Au lieu de prendre une semaine avec un développeur, ça prend un jour avec Figma, disons. Sauf qu'aujourd'hui, en 30 minutes, je génère trois front-ends avec mes trois variations. Et non seulement j'ai trois variations, j'ai des maquettes interactives, mais je peux cliquer, je peux remplir les champs, je peux avoir les animations, les messages d'erreur. Donc je pense que ce genre d'outil va disparaître. Ce qu'on voit, c'est vraiment de générer le front-end.

Terry: Ouais, là-dessus, juste pour rebondir, parce que moi, je fais pas mal de formations en ce moment auprès d'équipes Product Design et Product au sens large. Et effectivement, c'est une vraie question qui, en fonction des profils que j'ai en face, ils sont plus ou moins d'accord. On va se... Une question que je pose en tout cas, qui va dans la lignée que tu viens de dire, c'est que des outils comme Figma, ils avaient effectivement pour vocation à pouvoir faire baisser le coût d'itération autour de qu'est-ce qu'on veut construire avant de passer trop de temps à le construire, parce que ça coûtait très cher de produire ce code. Mais là, il suffit juste de parler pour que le code soit généré. Le delta que je vois en tout cas sur le terrain, c'est que les entreprises n'ont pas encore toutes connectées à un design system bien carré sur du storybook ou autre, avec un MCP. avec des choses qui permettent effectivement d'arriver là-dessus dans un contexte existant. Mais une fois que ça, ça aura été récupéré, effectivement, ça pose des vraies questions sur la pérennité de ces outils-là. Après, ils vont peut-être aussi savoir se réinventer. Figma est quand même vachement déployé dans les grandes entreprises. Ils font beaucoup de choses autour de l'IA. Mais ce sont, en tout cas, je te rejoins, de vraies questions sur ces outils-là. Et ce n'est pas pour rien, je pense que Figma est très, très actif en ce moment, un peu sur tous les pans du product et du design. Parce qu'ils sentent qu'effectivement, le vent tourne très vite avec la générative.

Adrien: Complètement. C'est pour ça qu'ils ont sorti Figma Make. Après, ils se sont fait un peu avoir par Anthropic. Tu connais l'histoire ?

Terry: L'histoire sous le capot avec la sortie de Cloud Design et Make, non. Mais si t'en as...

Adrien: En gros, il y avait quelqu'un du board d'Anthropic. Je crois que c'était le CPO d'Anthropic qui était au board de Figma. Un truc comme ça. Et deux jours avant la sortie de Cloud Design, il a resigné de son poste au board de Figma. Parce qu'ils ont sorti Cloud Design chez Anthropik pour aller taper directement dans les clients de Figma, finalement. Donc, c'était vraiment un coup un peu border limit. Enfin, perso, je trouve. Mais bon, après, c'est la guerre commerciale. Yes. Mais du coup, pour revenir à ce que tu disais. Donc là, juste sur la partie maquette, c'est une chose. Aujourd'hui, clairement, le gros du sujet sur lequel tout le monde s'arrache les cheveux, c'est les développeurs qui ont du coup passé beaucoup moins de temps à écrire du code. Mais on se rend compte qu'en fait, le métier de développeur, c'est pas du tout qu'écrire du code. s'il y en a qui l'avaient oublié. Le métier développeur, c'est de la conception architecturale. Avant d'écrire du code, je reçois une fonctionnalité métier, je dois la transcrire dans l'architecture du produit, technique, comment je vais interfacer, dans quel module, quelle sorte de connecteur je vais faire. Il y a toute une réflexion sur des ateliers. Ensuite, on génère du code avec l'autre code, on lui donne des infos, il se débrouille. Ensuite, on va avoir des phases de review. Donc, par soi-même, par des pairs, par des agents. Et du coup, aujourd'hui, la majorité du travail se concentre dans les phases de conception. En tout cas, c'est ce qu'il faut. Et dans les phases de review. Encore une fois, c'est ce qu'il faut. Ce qu'on voit dans plein d'équipes, je pense que tous les techs qui nous écoutent le ressentent, le vivent. C'est la souffrance de la review. C'est-à-dire, avant, une review, par semaine, je fais 5-6 reviews. la vitesse de création de code par mes collègues et ce qu'elle est. Donc, on passe plus de temps à écrire du code qu'à relire du code. Aujourd'hui, vu qu'écrire du code, enfin générer du code, ça se fait en quelques minutes, du coup, il y a beaucoup plus de reviews. On a 10 fois plus, 15 fois plus, 20 fois plus de reviews à faire par semaine. Et finalement, la majorité de notre temps en tant que développeur, c'est de faire des reviews, de faire de la conception et des reviews. Et c'est vrai que ça change complètement le paradigme du métier. Et notamment, ce qu'on voit, il y a une espèce de... de fatigue intellectuelle et mentale. Je ne sais pas si tout le monde la ressent, mais en tout cas, c'est quelque chose que j'ai vu dans plusieurs équipes, pas que la mienne, sur des communautés de CTO qui discutent. C'est la fatigue mentale, en fait, de passer sa journée à faire des tâches qui demandent beaucoup de concentration. C'est bon ?

Terry: Ouais, vas-y, continue.

Adrien: En gros, ce qui se passe, c'est que typiquement, avant, dans le journal de développeurs, je fais de la conception pendant une heure, puis après, j'écris du code pendant quatre heures. sur ces 4 heures, il y a 3 heures de code ultra simple, c'est du code bateau, où je plug des trucs, où je réfléchis pas trop, et c'est là que mon cerveau se repose. Et ensuite j'ai une heure de code très compliqué où je me concentre, et puis ensuite j'ai une heure de review. Mais du coup dans ma journée, j'alterne entre des tâches qui demandent une haute capacité cognitive et des tâches où c'est un peu plus détente, un peu plus mécanique. Et aujourd'hui ce qu'on voit c'est que finalement dans une journée, on a que des tâches où il faut vraiment se concentrer, des tâches à haute capacité cognitive, où il faut relire des kilomètres de code, comprendre l'architecture, etc. Donc c'est vrai qu'il y a une certaine fatigue à la fin de la journée où le cerveau, il fume.

Terry: Hyper intéressant là-dessus. Donc ce que j'allais te demander, c'est vous, du coup, donc vous faites encore toutes les reviews dans votre process de développement aujourd'hui, de la construction de votre produit. Vous gardez la main complète sur ces reviews ? Ou vous avez déjà commencé à avoir des choses que vous laissez automatiquement review par d'autres agents de code et des choses sur lesquelles vous voulez garder la main ? Parce qu'évidemment, il y a un moment quand c'est la machine qui produit, en fait, si en face c'est un humain qui filtre, soit tu acceptes que du coup tu ne gagnes pas du tout la productivité que tu aurais pu avoir sans ça, soit tu acceptes de lâcher un peu du lest et de faire confiance à la machine sur des choses où en gros ce qui va plus compter ça va peut-être être l'aspect fonctionnel que ça marche derrière versus le risque que tu es prêt à prendre sur le fait qu'il y ait certaines choses qui n'auraient pas été gérées.

La review agentique, la review humaine et le triage des pull requests

Écouter à 17:17

Adrien décrit un processus de review en plusieurs étapes, avec une review agentique en amont sur le plan d’architecture puis sur le code avant la review humaine. Il explique aussi comment les pull requests sont triées entre review auto, light et en profondeur selon la reproductibilité, la réversibilité et l’impact business.

Adrien: C'est exactement ce genre d'arbitrage. Mon avis personnel c'est qu'on va rentrer dans une époque où il va falloir accepter de ne pas... qu'il n'y ait pas des humains qui relisent la totalité du code. Après, il faut comprendre quel est le code qu'on ne peut pas faire relire et quel est le code qu'on peut faire relire selon sa criticité. Nous, aujourd'hui, on a un processus de review qui intervient à plusieurs endroits. Donc, quand on fait une fonctionnalité, il y a forcément un atelier. Alors, il n'y a pas toujours un atelier de cadrage tous ensemble, mais au moins, on discute de comment on va faire. Et en amont, avant d'écrire du code, on demande à Cloud Code de générer un plan d'architecture, de comment cette fonctionnalité va s'insérer dans l'architecture existante. Une fois qu'il a généré son plan, on a une première review agentique, c'est-à-dire qu'on va demander à Cloud Code, à notre session, de review le plan qu'elle a généré avec un tas d'instructions particulières sur des particularités architecturales, des problèmes de sécurité, d'isolation de données, etc. Pour qu'il y ait une première phase de review du plan. Donc ça, c'est une première review qui se fait en amont de l'écriture. Cloud Code review son plan. Ensuite, il y a la phase d'implémentation. Donc voilà, Cloud Code va implémenter tout ce qu'il faut, le code, les tests. Et ensuite, avant que l'humain review, on va avoir des reviews aussi agentiques. Donc on a une première review, c'est la complétude métier. Donc est-ce que Cloud Code a bien implémenté toutes les fonctionnalités qu'il fallait implémenter pour cette tâche ? Donc ça, c'est la première review pour être sûr qu'il n'y rien qui soit oublié. Ensuite, il y a une review classique, un peu sur les éventuelles failles de sécurité type OWASP. les patterns d'architecture, des choses comme ça, en fait, avec toutes nos règles de code sur la code base, donc tous nos skills qui expliquent comment coder sur cette code base. Et ensuite, on a aussi une review qui va simuler l'exécution du programme. Donc ça, c'est la troisième review. On demande à Cloud Code de simuler dans ses reasoning tokens l'exécution du programme. En fait, c'est exactement comme un humain. Un humain, quand il relie du code, il se dit, alors cette fonction, si je l'appelle avec ce paramètre, ça va aller dans ce if, ça va retourner ici. Si j'appelle avec ce paramètre, ça va faire ça. C'est la même chose. On demande à Cloud Code de simuler ces appels de fonction, ce call graph dans ces reasoning tokens, et ça, ça permet de choper plein de bugs d'exécution, des edge case, des rest conditions, des choses de ce genre. Et après, donc là, ça fait 4 reviews, une en amont, 3 en aval, une sur le plan, 3 sur le code. Après ça, l'humain qui a généré la PR, il doit aussi, lui, review le travail. donc le code qui a été généré, puis il ouvre une pull request, et là il demande une review humaine. Et aujourd'hui on a même une review agentique de plus, où on demande à notre assistant, on a un assistant qui est sur Slack, sur GitHub, un peu partout, c'est un assistant Hermès. En fait on l'assigne à la pull request, et ça le réveille, et du coup il va faire une review de plus, ça en met une couche, parce que c'est pas les mêmes modèles qu'on utilise, là c'est des modèles OpenAI qu'on utilise pour cette review.

Terry: Ok ouais, donc à la fois les modèles côté anthropique... pour générer modèle code OpenAI pour certaines régions sur donc ce que j'entends ce que je comprends là c'est quand même il y a un humain qui regarde au bout de la chaîne le code produit sur la paire donc vous n'avez pas encore de phase où il y a des bouts de code qui sont produits pour lesquels vous mergez directement ça sans

Adrien: avoir l'humain qui alors il y en a en fait en gros du coup quand on assigne notre assistant où on peut le faire depuis son poste il y a un skill cloud code on fait un triage de la pool request on a trois labels on a review auto Donc ça, en fait, c'est une pull request qu'on n'est pas obligé de review. On assigne quand même les gens, ça permet de comprendre qu'est-ce qui passe, qu'est-ce qui est émergé, mais si au bout de deux jours, il n'y a personne qui a review, c'est pas grave, on merge. Ensuite, on a light, une revue light, ça veut dire qu'il faut faire une revue plutôt du métier, et de se dire, bon, ce que mon collègue a voulu faire dans cette pull request, est-ce que ça fait sens ? Est-ce que ça s'inclut bien avec nos autres fonctionnalités, etc. Et ensuite, on a une review en profondeur, un tag pour review en profondeur. Là, ça veut dire qu'il faut vraiment... review le code et s'assurer que tout fonctionne correctement. Ce qui est intéressant pour classifier, il y a plein de méthodes de faire, on peut faire un petit bonheur à la chance, dire ah oui ça c'est critique ou pas, c'est de prendre trois dimensions. Donc il y a une première dimension, c'est la reproductibilité par les agents. C'est-à-dire, est-ce que mon système agentique a été capable de tester cette fonctionnalité de bout en bout ? Je te donne un exemple. Imagine que tu as une interface où tu crées un nouveau formulaire, est-ce que tu as demandé à ton cloud code de lancer Google Chrome et de tester en cliquant sur ce formulaire pour voir s'il fonctionne ? Si oui, ça veut dire que tu as réussi à reproduire la fonctionnalité. Donc niveau reproductibilité par ton agent, là tu passes. Il y a certaines fonctionnalités de bout en bout qui demandent de spawn des serveurs chez AWS, d'avoir une queue RabbitMQ, des choses comme ça. C'est très difficile de faire de bout en bout. Ensuite, il y a la réversibilité. Donc à quel point le changement que tu es en train de shipper, tu peux revenir en arrière facilement. Donc ça, je te donne dans le mille. Si c'est du front-end, super facile. Pour revenir en arrière, tu revertes, on redéploie l'ancienne version. C'est sur du code backend, en général, ça peut passer. Par exemple, là où c'est compliqué, c'est si tu as modifié le schéma de la base de données. Là, ça devient très difficile de revenir en arrière. Les données qui ont été écrites, et puis comment on fait en attendant, et puis comment on fait une migration dans l'autre sens, c'est beaucoup plus compliqué. Et le dernier point, c'est l'impact sur ton business. Donc, à quel point, s'il y a une erreur dans cette fonctionnalité que tu es en train de shipper, ça peut impacter tes clients. Donc ça peut être soit parce que la fonctionnalité principale de ton application ne marche plus, save 0, erreur save, anomalie save 0, tout le monde sur le pont, ou ça peut être parce que ça va nuire à ton image. Par exemple, tu fais fuiter des données entre plusieurs de tes clients sur ton SaaS. Ou alors, save 0, c'est par exemple ton pipeline de paiement qui ne marche plus. Et donc avec ces trois dimensions, ça peut te donner une note entre 0 et 10. Et du coup, ça te permet d'évaluer si une pull request, tu vas pouvoir l'amerger un peu rapidement ou pas. Si tu es plus vers zéro, tu peux dire qu'on la merge et puis ce n'est pas grave, on pourra la revert facilement.

Terry: Hyper intéressant. On va remonter un peu après, on va revenir sur vos retours aujourd'hui dans ton équipe avec ça comme process. Mais si on remonte sur la partie produit, du coup besoin à la base pour lesquels vous allez construire des choses. Aujourd'hui, vous le gérez comment ça ? Donc ce que tu disais, vous avez un UX à temps partiel. De ce que je comprends qui est plus là sur la partie architecture de l'information, flow utilisateur, donc plus centré d'un point de vue produit au sens ergonomie du terme, mais sur la partie plutôt product business et compréhension de qu'est-ce qu'il faut construire, là où il faut mettre du temps ou du token versus à un autre endroit. Comment est-ce que vous le gérez ça ?

Comment Maleus capte les besoins produit auprès de ses clients

Écouter à 23:40

Adrien explique que, chez Maleus, le contexte est particulier : la startup compte aujourd’hui une quinzaine de clients, qu’ils voient presque chaque semaine, et deux personnes se chargent des interviews, ce qui facilite la capture des besoins. Il précise aussi que leur produit remplace leur propre métier, donc ils savent assez directement de quoi ils ont besoin pour gérer le SDLC et, par exemple, traiter les logs et les erreurs en production. Terry souligne ensuite que les utilisateurs ne viennent pas forcément du monde du logiciel, et Adrien répond qu’ils récupèrent leurs retours en direct, avec l’aide de leur UX designer.

Adrien: Alors, il y a plusieurs choses qui font que notre cas est un peu particulier. Le premier cas, c'est qu'on est une startup. Aujourd'hui, on a à peu près une quinzaine de clients. Donc, on les voit quasiment toutes les semaines. Déjà, c'est plus facile de capter les besoins quand on parle à ses utilisateurs toutes les semaines.

Terry: Vous les voyez tous les six, du coup, ou il y a une personne ? Non,

Adrien: il y a deux personnes qui s'occupent de faire les interviews. Et la deuxième chose qui est particulière, c'est que le produit qu'on crée, c'est un produit qui remplace notre métier. Et nous, on est des experts dans notre métier. C'est-à-dire qu'on ne fait pas un produit pour les experts comptables ou pour je ne sais pas quel autre métier. On fait un produit. Alors, les gens qui utilisent Maleus, ce ne sont pas des développeurs, ce ne sont pas des gens tech. Mais la manière dont ils l'utilisent, c'est pour créer du logiciel. On fait un produit qui crée du logiciel. Et ceux qui l'utilisent, ce ne sont pas forcément des gens qui sont experts en logiciel. Enfin, ce ne sont pas des gens qui sont experts en logiciel. Comme PennyLane, ils font un produit pour gérer la comptabilité, mais les gens qui l'utilisent ne sont pas forcément des experts en comptabilité. Du coup, c'est comme si des comptables... C'est comme si Pennylane ne recrutait que des reconversions de gens qui étaient comptables et qui se mettaient à être développeurs. Ils connaissent leur métier, ils savent ce qui va être utile ou pas. Nous, on est un peu dans cette situation. Du coup, on sait ce dont on a besoin pour gérer le SDLC. On sait ce dont on a besoin, je te l'ai dit, voilà, toutes les étapes. Par exemple, une fois que tu es sur la phase d'exploitation, si tu n'as pas un outil qui permet de récolter les logs et les erreurs qui surviennent en production, tu ne pourras pas les corriger. Et la personne qui s'occupe de cette application, elle va se retrouver bloquée parce qu'elle ne pourra pas corriger ses erreurs en production. Donc c'est un peu plus facile. Donc on est vraiment dans une position de confort et surtout par notre taille aujourd'hui qui nous permet de ne pas avoir besoin de faire de la discovery, tout le cycle produit en amont classique.

Terry: Ok, je vois ce que tu veux dire. Après, je te donnerai ça quand même sur le point que, comme tu l'as dit, à la fin, ceux qui vont utiliser votre produit, ça va être des gens qui ne viennent pas spécialement du monde du logiciel. Donc sur la partie Même comment tu présentes l'information, les patterns vers lesquels ils vont être plus ou moins à l'aise en termes de compréhension, etc. Là-dessus, aujourd'hui, c'est juste votre UX, de ce que je comprends, qui va vous aider à travailler.

Adrien: C'est ça. On prend les retours de nos utilisateurs en live parce qu'on les voit régulièrement. Mais c'est surtout notre UX designer qui nous aide beaucoup là-dessus.

Terry: Très clair. Pour revenir du coup sur ce process que tu décrivais pour construire ce produit-là, que vous avez mis en place en interne, quels sont aujourd'hui, avec le recul que vous avez, déjà ça fait combien de temps à peu près que vous avez ce process qui tourne pour vous ?

Les premiers apprentissages sur le front-end généré et les skills

Écouter à 26:14

Adrien explique que le travail est très itératif et que les briques du projet sont construites depuis un peu plus d’un an. Il détaille ensuite pourquoi le front-end généré permet à des profils non techniques de créer rapidement des maquettes et de les déployer en environnement de preview pour recueillir du feedback plus tôt. Adrien insiste aussi sur l’importance des skills et des instructions propres à la code base pour guider les agents, suivre l’architecture du projet et éviter certains anti-patterns dès le départ.

Adrien: C'est vraiment un travail itératif. C'est-à-dire que toutes les briques qu'on a aujourd'hui, disons que ça fait un peu plus d'un an qu'on les travaille.

Terry: Que vous les travaillez, oui. Donc sur le recul à date, en fin octobre 2026, que vous avez par rapport à ce mode de fonctionnement, quelles sont les choses que tu vois bien fonctionner ? Donc là, pour d'autres boîtes, tu vois, qui auraient des profils tech, qui veulent un peu mettre à jour la manière dont ils font du logiciel versus les choses sur lesquelles ça fonctionne un petit peu moins bien, où vous vous êtes cassé les dents, vous vous êtes dit, bon, ça, on arrête d'essayer de l'automatiser, ou ça, ça ne marche pas bien. Quels sont un petit peu les premiers apprentissages, après un an, à être vraiment dedans et repenser le SDLC pour construire un produit ? Je pense que... Alors, je vais l'axer vraiment dev, mais du coup, je vais commencer par les trucs non dev.

Adrien: Encore une fois sur la partie front-end maquettage, en fait aujourd'hui c'est tellement mieux de pouvoir créer du front-end, de laisser n'importe qui, des products, des designers, des gens pas tech du tout, de créer du front-end et de le push sur une app preview. Donc il n'y a pas de criticité, c'est pas de production, on s'en fiche si le code n'est pas propre, il y a des bugs, juste pour que les gens puissent tester rapidement. tester des idées rapidement, partager avec les autres personnes, les autres stakeholders et avoir des retours très rapidement. C'est ça l'idée, c'est pouvoir, normalement pour récupérer du feedback, en tant que product manager, t'es obligé de te taper toutes les étapes. Donc on va faire des maquettes, on va faire le dev, on va le déployer et maintenant il y a des utilisateurs qui l'utilisent et j'ai récolte du feedback. Ça fait trois mois, on est bonne boîte. Là aujourd'hui, en tant que product manager, en tant que UX designer, je peux générer un front-end au-dessus de l'application existante. le déployer dans un environnement de preview. Par exemple, on a des environnements de preview qui sont gérés par notre assistante Hermès aussi, qui les déploie à la demande. Et ça nous permet très rapidement de tester des choses, de partager avec d'autres collègues, à partager avec certains clients, pour récolter ce feedback vraiment tout de suite en amont, avant de se lancer dans des développements entre guillemets sérieux, où ça passe par le staging, la QA, la prod, etc. Ça, c'est vraiment sur cette partie en amont, je trouve que ça change complètement la façon de bosser. Après, sur la partie dev, vraiment, Le number one. Alors c'est marrant parce qu'il y a un article qui est sorti il n'y a pas longtemps qui a fait beaucoup de bruit parce qu'il est sorti sur le blog de Martin Foller où un mec prétend que le harness ça ne change rien. Et surtout quand il dit harness, il prétend que c'est le modèle qu'on utilise et les instructions ça ne change rien.

Terry: Explique du coup la notion de harness.

Adrien: Un harness c'est les outils qu'on va fournir à un modèle, dans un système agentique qui va lui permettre d'interagir avec le code. Par exemple, aujourd'hui on dit que Claude Code c'est un harness. Alors le thème est un peu flou, on ne sait pas si Claude Code c'est un harnais, ou si le harnais on considère que c'est Cloud Code plus les instructions qu'on lui met à disposition. Aujourd'hui, c'est plus ça la définition, c'est le Claude Code, ou le open code, etc., plus les instructions. Souvent, plutôt ça. Et du coup, bon bref, cet article prétend que ça ne change rien, alors que c'est complètement faux, l'étude est falsifiée. Il ne fait ça que sur un seul cas d'usage, ultra simple. Aujourd'hui, le truc qui apporte le plus de valeur, c'est vraiment le fait d'avoir des instructions qui expliquent... Comment travailler sur sa code base ? Chaque code base est différente. C'est ça la beauté du métier, ou la complexité, je ne sais pas. Mais chaque code base est différente. Il y a une manière de faire tel genre de choses, tel genre de choses. Donc ça, c'est des instructions spécifiques à la code base, sous la forme de skills. Par exemple, nous, on a une architecture de monolithe modulaire, avec des modules nest, avec une couche de data, une couche de présentation, une couche de service et une couche de test. C'est l'architecture qu'il faut suivre chez nous. Donc l'agent, il faut qu'il le sache. Et la deuxième chose, c'est d'avoir des instructions qui vont aider à cacher des bugs ou des erreurs, des anti-patterns, avant qu'ils soient codés. Je donne un exemple, par exemple, si tu envoies un très gros fichier à ton application, il faut le streamer. Et pareil, si tu télécharges un très gros fichier, il faut le streamer pour éviter de surcharger la mémoire. Donc tout ça, c'est des instructions que tu vas pouvoir mettre sous la forme de skills et qui vont aider tes agents à coder correctement. Et du coup, par extension, les développeurs qui les utilisent vont aussi coder, vont faire du meilleur code, surtout du code qui va être plus uniforme. Une seule façon de faire, les agents ils le respectent sans rien demander à personne, ça permet vraiment de mieux travailler sur une code. C'est vraiment le truc à travailler dès le début. Par exemple, nous on a une soixantaine de skills aujourd'hui.

Terry: Donc vraiment encoder la manière dont ton projet est construit, dont tu veux que le code soit produit dans ton projet au travers de compétences, de skills qui vont permettre derrière... de guider ces agents qui vont aller taper dedans et utiliser tous ces skills pour s'assurer qu'on a une certaine cohérence dans la manière dont... Donc ça c'est ton apprentissage number one de ce que vous avez...

Adrien: C'est le truc qui apporte le plus de valeur.

Terry: Est-ce qu'il y a des choses que vous avez testées en ayant bon espoir au début et après vous avez dit non là on n'est pas au niveau ou en fait non ça ne marche pas si bien que ça ?

Adrien: En fait j'ai réfléchi parce que techniquement il y a plein de choses qu'on a testées mais du coup je ne m'en souviens pas forcément.

Terry: De gros paris tu vois, des trucs où... Vous aviez peut-être l'espoir que, à date, les modèles aient résolu. C'est une problématique qu'ils n'ont toujours pas résolue.

L’architecture logicielle, principal point faible des modèles

Écouter à 31:22

Adrien explique que les modèles sont bons pour générer du code, faire du front-end ou chercher des bugs et des failles de sécurité, mais qu’en architecture logicielle ils ne sont vraiment pas bons. Il dit qu’ils dupliquent du code, ne réutilisent pas et ne respectent pas les principes solides ni la séparation des concerns. Terry enchaîne en demandant si, malgré les progrès récents, on n’atteint pas déjà une sorte de plafond de verre sur ce que les modèles savent produire.

Adrien: Ah, ça, c'est clair. En tout cas, ça, c'est l'architecture. Aujourd'hui, l'architecture logicielle, vraiment, les modèles ne sont pas bons. Autant, sur plein de choses, ils sont bons. Générer du code, faire du front-end, chercher des bugs, chercher des failles de sécurité. Sur l'architecture logicielle, en général, ils ne sont vraiment pas bons. Ils dupliquent du code, ils ne réutilisent pas, ils respectent pas. pas les principes solides, la séparation des concernes. Nous, c'est vraiment aujourd'hui ce qui nous freine le plus à, entre guillemets, lâcher les vannes des coding agents sur notre produit. C'est que dès que tu as une architecture logicielle qui est un peu complexe, donc dès que tu sors du logiciel business, crud, etc., avec des règles métiers, ils ne sont pas bons, vraiment.

Terry: Donc crud, acronyme pour create, update, delete,

Adrien: j'ai oublié l'air. C'est en gros, voilà.

Terry: C'est quand tu veux... faire des edits dans une base de données.

Adrien: C'est quand tu affiches une table avec des informations et quand tu veux modifier des données avec un formulaire.

Terry: Yes. Ok, très clair. Donc sujet d'architecture pour lequel... Est-ce que... Moi j'ai un sentiment, je suis curieux de savoir si tu le partages ou pas. Donc évidemment, il y a eu un gap à partir de fin 2025 sur la capacité des modèles à produire du code, notamment au départ avec Opus, ce qui a fait gagner un peu d'avance à Cloud Code face à Codex. Maintenant, moi je suis un power user de Codex, donc je suis biaisé, mais je trouve que Codex est quand même assez ouf. Mais donc, fin 2025, il y a eu vraiment ce gap-là, au début Opus, puis après, les modèles d'OpenAI aussi, qui sont alignés sur la capacité des agents. Donc, en final, ce n'est pas si vieux que ça. Là, j'ai quand même le sentiment, donc on enregistre le redit en octobre 2026, qu'on arrive un peu à un... Alors, il y a des nouveaux modèles, on a Opus 5.5 côté Cloud, on a un côté Anthropic, on a Fable aussi, mais dans d'autres cas, on a Astra côté OpenAI. Mais j'ai le sentiment qu'on arrive un peu à un... Je ne sais pas si je peux dire plafond de verre, mais à un moment où... Ils font des machines plus grosses, mais en termes de ce que ça arrive à produire, on a déjà passé un premier palier. Je ne sais pas si on va passer un nouveau palier. Personne n'a de boule de cristal, ça va très vite. Ça peut changer, mais je suis curieux d'avoir. Est-ce que toi, tu partages ce sentiment-là depuis quelques mois ou pas ? Ou tu te dis, il y a un prochain truc qui va encore nous faire un breakthrough ?

Adrien: Pour être transparent, nous, dans Maleus, on a commencé avec Opus 4.5. Je me suis d'avant. En tout cas, ça Maret déjà avec 4.5. Et tout ce qu'ils ont sorti jusqu'à Opus 5, ça me... Ça marche plus ou moins pareil. Ça marche pareil, notre produit continue à fonctionner. Là, on a vraiment vu un gap, c'était Opus 5.5. Ils ont vraiment amélioré quelque chose. En gros, avant, pour comparer le prix des modèles, on comparait le prix des tokens en sortie et en entrée. Sauf que ça ne marche plus du tout de faire comme ça, parce que même si les modèles vont avoir le même prix, on va avoir des modèles qui vont être plus verbeux, qui vont demander plus de tokens, de reasoning tokens, donc la chaîne de pensée interne des modèles. plus de modernes, de token on output, etc. Donc ce n'est plus une bonne métrique. Aujourd'hui, il faut aller sur Artificial Intelligence, le site, qui permet de faire des comparaisons le coût par tâche. Aujourd'hui, c'est ça le benchmark. Et Opus 5.5 était 30% moins cher, à peu près, sur les tâches, et surtout beaucoup plus rapide. Nous, on a vu vraiment le temps de génération d'une version, donc c'est un sprintage antique dans Maleus, ça a été divisé par deux. Et le coût à peu près par 30%, à peu près comme ce qu'annonce Opus 5.5. Donc on voit des améliorations. Après, ils sont toujours nuls en architecture. Ça, on n'a pas vu trop d'améliorations. Je ne sais pas trop où ils concentrent leurs efforts. C'est compliqué de comprendre. Est-ce qu'ils les concentrent sur les maths ? Là, on a vu, on est en octobre 2026, donc il y a eu tous Ramdam sur OpenAI qui sort 700 problèmes de maths. Et tous les mathématiciens se disent, mon Dieu, on va mourir. C'est la fin du monde. Alors ça me fait un peu rire parce que dans la tech, Ça fait deux ans qu'on se prend des claques. On se prend des modèles. Les développeurs, notre métier a complètement changé. On n'écrit plus une seule ligne de code. C'est comme si le mathématicien n'écrivait plus une seule ligne de maths. Je ne sais pas exactement le métier. Mais bon, on encaisse. Dans la tech, on encaisse, on encaisse. Et c'est vrai qu'on a quand même cette capacité à s'adapter rapidement. Donc voilà, tout l'écosystème s'adapte. Mais ce n'est pas forcément toujours facile. Je ne sais pas. Je pense qu'aujourd'hui, on est plutôt dans une phase où l'écosystème tech est en train d'encaisser ce qu'on a pris en 2026. Quand même, là, c'est dingue. D'ici la fin de l'année, quasiment plus personne, je ne sais pas, dans 6-9 mois, plus personne n'écrira de code du tout. Et maintenant, l'idée, c'est qu'est-ce qu'on fait avec ça ? Quelles sont les bonnes pratiques ? Comment on structure une DSI ? Quels sont les outils ? Quelles sont les choses à mettre en place ? Et ce qui est intéressant, c'est qu'avant, les changements se faisaient quand même assez lentement. Et donc, les boîtes qui étaient à la tête de la cohorte, elles redistribuaient leurs bonnes pratiques. Aujourd'hui, tout le monde est dans le flou. Tout le monde apprend à marcher en courant ou en tombant, je ne sais plus comment on dit. Donc c'est vraiment une période passionnante pour le métier en tout cas.

Terry: Yes, c'est aussi pour ça que j'ai quand même un gros virage sur le podcast à faire beaucoup d'épisodes autour de l'IA, mais justement pour ça, parce que personne n'a... eu le temps de laisser décanter les choses. On n'a pas le temps de laisser décanter, ça court en permanence et donc on apprend en partageant le plus possible. Tu me fais un passation parfaite pour aller justement un peu vers le sujet de aujourd'hui les clients que vous accompagnez. Qu'est-ce que tu vois justement sur l'état des DSI qui veulent prendre ce virage-là ? Les choses qui peuvent être difficiles pour elles, les choses sur lesquelles elles ont de la valeur, sur lesquelles il faut qu'elles capitalisent et qu'elles fassent attention justement de... De ne pas perdre cette valeur-là, parce qu'évidemment, quand on a des organisations qui sont là depuis des dizaines d'années, il n'y a pas tout qui est à jeter parce que d'un coup, le coût du code tombe proche de zéro. Il y a plein de choses, comme tu l'as dit aussi, avant même l'IA générative, le métier de développeur allait bien au-delà de juste la production de code. Donc, quelles sont les choses, là, un peu les tips, tu vois, pour des DSI, des CTO qui écouteraient, qui se diraient, OK, bon, il faut qu'on réinvente notre SDLC, mais sur quoi je peux capitaliser ? Quelles sont les choses sur lesquelles, maintenant, je peux un peu lâcher mon attention parce que l'IA va s'en charger ? Comment prendre ce virage-là ?

Le harnais d’entreprise, les AI gateways et la conduite du changement

Écouter à 37:23

Adrien décrit plusieurs niveaux de maturité autour des coding agents, du déploiement de base jusqu’au « harnais d’entreprise » avec ses instructions, ses agents de revue de code et de documentation. Il enchaîne avec les AI gateways, le contrôle des sorties et des dépenses, puis avec la gouvernance et la conduite du changement, avant que Terry n’interroge le passage d’un gain individuel à un gain collectif à l’échelle de l’organisation.

Adrien: Je dirais qu'il y a plusieurs moyens de comprendre un peu la maturité et plusieurs, entre guillemets, cases à cocher. Une des premières cases, c'est tout simplement déployer des coding agents et les donner aux gens pour qu'ils puissent commencer à les utiliser. Après, selon la maturité des boîtes, on peut avoir un contrôle plus ou moins fin là-dessus. Il y a des boîtes, même des très grosses boîtes, qui distribuent du cloud code à tout le monde et se retrouvent avec des factures énormes, puis ensuite, serrent la vis. Il y a des boîtes qui sont plus prudentes, Donc ils vont d'abord... mettre en place les outils et les process. Typiquement, aujourd'hui, ce qui se voit beaucoup, c'est ce qu'on appelle le harnais d'entreprise. On en parlait tout à l'heure. Le harnais, c'est un cloud code, un open code, un codex, peu importe, le premier système agentique qui permet de générer le code, et autour, toutes les instructions et skills de l'entreprise. Ça peut être sur chaque stack de l'entreprise, ils ont une stack en Java, une stack en TypeScript, une stack en C-Sharp, les instructions sur comment coder sur ces stacks-là, sur chacun des projets. C'est quoi les bonnes pratiques de sécurité, les bonnes pratiques autour de la RGPD, aussi des instructions sur la charte graphique associée au design system pour l'utiliser correctement. Donc en fait, c'est de créer tout ce harnais d'entreprise. C'est aussi créer les agents qui vont faire la code review, les agents qui vont générer la documentation. Et ensuite, d'avoir de distribuer aux développeurs ce harnais d'entreprise pour qu'ils puissent utiliser l'IA dans les contraintes de l'entreprise. Une fois qu'on en arrive là, il y a aussi une question qui se pose, c'est on utilise quelle IA ? comment, avec quel contrôle. Donc là, on arrive sur un deuxième gros sujet, qui est le sujet des AI Gateway. Donc les AI Gateway, ça peut être des choses très publiques comme Open Router, ça peut être celle de Databricks, ça peut être celle de LG, qui est une boîte française qui fait une AI Gateway aussi. C'est de contrôler ce qui sort. Donc par exemple, en mettant des règles pour dire, si on voit des informations personnelles qui sont détectées dans les promptes, on peut les bloquer en amont avant de les envoyer à Anthropic, Amazon, etc. Mais aussi de faire plein de choses autour de l'optimisation de la consommation, du modèle routing, donc voir quelle demande veut aller sur quel modèle, de mettre des limites de dépenses. C'est vraiment le panneau de contrôle de la consommation de l'IA, donc c'est forcément quelque chose à mettre en place aussi au sein d'une DSI. Et puis voilà, après c'est beaucoup de gouvernance et de conduite du changement, comme d'hab, ça c'est vraiment le mot que j'entendais. Quand j'étais à l'école, j'entendais le mot conduite du changement et puis personne ne s'y intéressait. Mais je me rends compte avec l'expérience que c'est la chose la plus compliquée. C'est comment on fait pour amener les équipes sur les bonnes pratiques, sur les nouveaux outils, les accompagner à utiliser ces technos.

Terry: Et c'est très clair là sur un peu ces tips. Je suis curieux de savoir aussi vous. Donc, vous êtes une équipe de six personnes. Vous avez huit, excuse-moi, six techs. Voilà, l'absurde. Du coup, sur... Sur la productivité des C-Tech, vous avez un gain à la fois de productivité individuelle et potentiellement, vous pouvez aussi, à 6, globalement, pas trop vous remarcher dessus sur les tâches sur lesquelles vous travaillez. Quand on parle de contexte de boîtes qui ont des centaines de salariés, des centaines de teams product and tech, il faut réussir aussi à avoir ce gain non pas de productivité individuelle, mais de productivité de groupe. Là-dessus, qu'est-ce que tu vois un peu comme... Peut-être bonne pratique aussi de se dessiner, parce que déployer à tout le monde un cloud code et coding agent et avoir une AI gateway qui fait en sorte que globalement, il n'y a pas n'importe quoi qui est fait sur les modèles, OK, ça va permettre à tout le monde de prendre en main les choses, mais ça ne va pas résoudre... Alors, il y a le harnais d'entreprise avec les skills pour faire en sorte que les différentes bases de code soient attaquées de la bonne manière, mais ça ne va pas nécessairement impliquer un gain de productivité global justement de l'organisation. Qu'est-ce que tu... Tu peux voir déjà comme bonne pratique se dessiner, s'il y en a ou s'il n'y en a pas, les questions qui se posent en tout cas.

Pourquoi le gain de productivité ne se limite pas aux développeurs

Écouter à 41:14

Adrien explique que les gains d’outillage profitent surtout aux développeurs, alors que le vrai écart se trouve selon lui dans les autres métiers du SDLC, notamment les profils produit et EPM. Il évoque des outils comme Claude Desktop ou ChatGPT Desktop connectés à des sources comme Confluence, Drive et Jira, en disant que cela peut déjà faire gagner beaucoup de temps sur le métier d’EPM. Terry prolonge sur les fonctions produit, les usages de Cloud Chat et Cloud Code, puis lance la discussion sur l’évolution attendue des profils tech demain.

Adrien: Encore une fois, je suis resté dans ce que j'ai dit, c'était vraiment des choses centrées autour des développeurs. Mais ce qui se passe, c'est que les autres parties du SDLC sont un peu les dernières roues du carrosse en termes d'outillage, notamment parce que Cloud Code, Codex, etc., c'est vraiment pour sa cible les développeurs. Aujourd'hui, il n'y a pas le Cloud Code des PM. Il n'y a pas vraiment d'outil agentique aussi incroyable que Cloud Code. pour les développeurs qui existent pour les PM. Donc c'est vrai que c'est plutôt tous ces autres profils, comment on fait pour les outils correctement. Parce que encore une fois, les chiffres, c'est 17 fois plus rapide. Les développeurs, 17 fois plus rapide. La livraison de features en prod, c'est 1,3 fois. Donc ce gap, en fait, il est dans les autres métiers. Donc aujourd'hui, ce que je vois plutôt dans les DSI, pour les développeurs, ça se fait plus ou moins facilement, etc. Mais ça se fait assez naturellement. Mais c'est plutôt pour les autres profils, comment on les outille. Donc comment on outille typiquement les products. parce que par exemple si les équipes sont sur Jira tant pis pour eux mais il y en a plein qui sont encore sur Jira l'IA de Jira, Rovo elle n'est pas vraiment utile rien à voir avec ce que peut faire Cloud Code donc comment on fait pour outiller ces profils, j'ai pas de réponse ultime mais ce qui se passe quand même c'est qu'aujourd'hui avec un agent comme Claude Desktop ou ChatGPT Desktop des choses comme ça qui est connecté en MCP un peu aux sources de connaissances type Confluence le Drive, les choses comme ça et aussi à Jira, on va quand même gagner beaucoup de temps sur le métier d'EPM. Ou alors des solutions intégrées comme ce qu'on fait nous, mais ça change complètement la manière de... Enfin, ça change la manière de bosser, parce que t'as plus la couche développeur à la fin.

Terry: Yes. Là-dessus, effectivement, sur les fonctions de produit, moi je donne des formations là-dessus, sur l'utilisation de CloudChat, et même après Claude Code, il y a aussi une partie, en fonction des profils d'EPM, tu vas en avoir d'ailleurs, qui construisent leur bibliothèque de skills orientés product dans CloudCode. D'autres pour lesquels ça va être déjà un peu aride de rentrer sur Cloud Code, donc ils vont rester sur Cloud Chat. Mais aujourd'hui, Cloud, en plus le harnais de Cowork a été réintégré dans le chat, donc on peut aller quand même assez loin juste avec l'application desktop, comme tu disais, de Cloud et les projets. Peut-être du coup, avant d'aller vers mes questions de fin d'échange, sur ce que tu disais, donc là, le produit que vous construisez, notamment, à terme, ça va permettre potentiellement, ça permet à des boîtes de s'affranchir d'une équipe de tech pour faire... pour construire des choses. Qu'est-ce que tu vois, toi, en termes d'évolution, justement ? Quels sont tes paris ? Plutôt, c'est très compliqué de savoir, mais tes paris sur le rôle derrière des ingénieurs demain dans la tech, avec toutes ces solutions qui arrivent très fort sur le marché et qui ont aussi des taux d'adoption assez forts. Donc, on voit des produits de vibe coding, comme le vote qui... Alors, ce n'est pas que vibe coding, justement, mais qui... qui ont des courbes d'adoption monstrueuses. Donc, quelles sont un peu toi tes prédictions sur l'évolution derrière de ce qu'on va attendre des profils tech ? Demain.

Adrien: Une grande question.

Vers quelles tâches les ingénieurs vont être redirigés

Écouter à 44:13

Adrien présente son AI Software Factory comme une troisième force de frappe, centrée surtout sur des logiciels internes à forte complexité métier mais à faible complexité technique, et envisage une réorientation des développeurs vers des projets plus complexes techniquement. Il compare cette évolution au passage des webmasters qui écrivaient du HTML et du CSS vers des applications type SaaS, après l’adoption des CMS par les équipes marketing. Terry évoque toutefois une possible saturation du marché et des pertes d’emploi, et Adrien reconnaît que certains développeurs pourraient devoir se reconvertir s’ils ne parviennent pas à travailler sur des projets plus complexes techniquement.

Adrien: Aujourd'hui, typiquement, la première chose, c'est que le positionnement qu'on a, nous, avec notre AI Software Factory, c'est qu'on ne remplace pas les ingénieurs. On fait d'autres choses. On travaille sur d'autres types de logiciels. On travaille surtout aujourd'hui sur les logiciels qui ont beaucoup de complexités métiers. Donc, tous les logiciels internes qui, aujourd'hui, n'existent pas ou sont faits avec des Excel ou même pas, mais qui n'ont pas beaucoup de complexités techniques. Donc, souvent, c'est des projets... qui pourrissent sur le bureau de la DSI, que de toute manière, en tant que développeur, c'est inintéressant à faire, et surtout très complexe, parce que je ne sais pas si vous faites un projet pour les contrôleurs de gestion, pour la boîte c'est super important, parce que ça permet de mieux calculer les marges, de récupérer plein d'argent. Pour un développeur, ça veut dire se palucher toutes les règles de contrôleur de gestion, et finalement faire juste des formulaires, des tables et des règles métiers. Donc il n'y a aucun intérêt, quasiment aucun intérêt technique. mais beaucoup d'intérêt métier. Et nous, c'est surtout là-dessus qu'on se positionne, même si on a aussi des trucs beaucoup plus complexes. Donc finalement, on ne remplace pas... Alors si, parce qu'il y a forcément des développeurs qui font ce genre d'application, mais on se positionne plutôt comme une troisième force de frappe. On a des développeurs en interne, une ESN qui bosse avec la DSI, et on peut utiliser ça pour ce genre de plateforme, ce genre de software factory, pour créer des logiciels. Donc finalement, ce qu'on voit, c'est qu'il y a une redirection des développeurs. Ils vont être redirigés. vers des projets plus techniques. Donc typiquement, une boîte comme Cloudflare, eux, ils ont besoin de très très bons ingénieurs parce que tout ce qu'ils font, c'est un scale absolument incroyable. C'est une échelle absolument incroyable parce qu'ils sont sur tout Internet. Ils font des choses très complexes. Ils ont besoin d'énormément d'ingénieurs. Et donc dans toutes les boîtes, on va avoir une captation, j'imagine, on va avoir une profusion de projets beaucoup plus complexes qui vont pouvoir être lancés parce qu'on va débloquer des profils d'ingénieurs qui travaillaient sur ces logiciels. plus simple à mettre en place, vers des logiciels plus complexes. C'est ce qu'on a vu typiquement pour les pages web. Aujourd'hui, même avant Cloud Code, personne ne faisait des pages web à la main. Même avant les IA, je veux dire. C'est-à-dire que l'équipe marketing, ils ont un CMS, ils ont du WYSIWYG, donc « What you see is what you get » . Ils déplacent des cartes et ils créent leur page WordPress, leur page sur HubSpot, etc. Il n'y a plus besoin de faire appel à un webmaster qui écrivait du HTML et du CSS. Pourtant, ces personnes-là... ils ne sont pas allés au chômage, ces personnes-là, elles ont évolué, elles ont commencé à faire des logiciels plus complexes, des applications type SaaS, avec du JavaScript, des interactions, et pas juste des simples pages web. Et je pense qu'on arrive dans une période où on va avoir encore une fois un report de toute une catégorie de développeurs qui bossaient sur une catégorie d'applications vers des problèmes plus complexes.

Terry: Intéressant, comme c'est évidemment la... Le verre à moitié plein, j'ai envie de dire, derrière cette révolution. Après, il y a aussi le fait qu'au bout d'un moment, il va y avoir potentiellement aussi une saturation du marché et qu'il y aura des personnes qui vont potentiellement perdre leur job. C'est compliqué. J'ai évidemment envie de croire au scénario que tu viens de décrire. Après, est-ce qu'on va aller vers là ? On verra. Mais c'est une analyse intéressante quand même.

Adrien: Après, je ne prétends pas que personne ne va perdre son job. Dans toutes les évolutions technologiques, forcément des gens qui sont qui soit décident eux-mêmes d'arrêter. Aujourd'hui, il y a eu plusieurs cas que j'ai vus de développeurs, même des développeurs seniors, qui veulent arrêter leur travail. Donc voilà, ça arrive. Et après, il y a des gens qui forcément ne vont peut-être pas reprendre le pas et travailler sur des choses beaucoup plus complexes techniquement et qui, du coup, devront se reconvertir vers autre chose. Donc c'est comme ça.

Terry: Yes. Avant d'aller vers mes questions de fin d'échange, est-ce qu'il y a un sujet en particulier dont on n'a pas parlé que tu aimerais mettre en avant, un point particulier ? Un message à faire passer ?

Adrien: Non, non, ça va, tu peux aller sur les questions.

Terry: Ça roule. Donc pour aller vers mes questions de fin d'échange, est-ce que tu as une conviction forte avec laquelle tu es en général en désaccord avec tes pairs ?

Adrien: Complètement, c'est ce que j'ai exprimé juste avant. Je pense que pour une immense majorité des softwares qui se créent actuellement avec des développeurs, on n'a plus besoin de développeurs. Typiquement, c'est tous les logiciels. En tout cas, c'est aujourd'hui. Et on va voir ce que j'en pense pour demain.

Pourquoi les logiciels de gestion simples n’ont plus besoin de développeurs

Écouter à 48:26

Adrien explique que les logiciels de gestion simples — ceux qui affichent et reçoivent des données via des formulaires, se connectent à un CRM ou à un ERP et appliquent des règles métier — peuvent déjà être faits sans développeurs. Il dit aussi que certains clients maintiennent même des logiciels assez gros sans qu’aucun développeur n’ait à relire ou écrire du code, et compare cette évolution à celle qu’ont vécue les webmasters il y a vingt ans. Terry réagit avec un exemple de logiciel métier construit par une personne non technique, puis Adrien détaille les gains de personnalisation, de délais et de coûts avant d’ouvrir la question de la préparation des équipes.

Adrien: mais typiquement tous les logiciels de gestion qui sont finalement assez simples. Donc quand je dis simple, c'est des logiciels qui finalement montrent des données et reçoivent des données via des formulaires, sont connectés avec un CRM, un ERP, etc. Appliquent des règles de métier, de transformation des données avec des calculs. Donc tous ces logiciels sont vraiment très simples à faire. Il n'y a aucune complexité technique, il y a juste une complexité métier. Et pour moi, ces logiciels, il n'y a déjà plus besoin de développeurs pour le faire. Alors, ce n'est même pas qu'une conviction, c'est ce que je vis au jour le jour. Enfin, voilà, nos clients, ils font ce type de logiciel, parfois des trucs qui sont assez gros, une quarantaine d'interfaces, d'écrans, sans avoir besoin qu'aucun développeur ne relise ou écrive du code. Et c'est des personnes qui n'ont aucune compétence technique, qui maintiennent, etc. Donc, pour moi, on est déjà dans cet air-là, c'est juste que ce n'est pas encore arrivé complètement de partout. Et c'est vrai qu'il y a beaucoup de personnes qui ne sont pas forcément d'accord. Voilà, un logiciel, ça a besoin de quelqu'un qui le maintient. Je pense qu'on est en train de vivre la page web, ce qu'ont vécu les webmasters il y a 20 ans. Les développeurs sont en train de le vivre maintenant. Il y a toute une partie du logiciel où on n'a plus besoin de human ni de notes à plat pour citer une vidéo assez connue. Et on verra dans le futur jusqu'où ça ira. Parce que pour l'instant, c'est ça. Et puis peut-être que demain, ce sera même ces logiciels complexes dont je parlais. Peut-être que même là, on n'aura plus besoin de développeurs qui lisent et écrivent du code. Je ne sais pas, j'en doute. J'aimerais bien me dire que non, on aura toujours besoin de développeurs. Mais bon, si on m'avait demandé il y a deux ans, est-ce qu'on aurait pu se passer de développeurs pour faire ce type de logiciel de gestion ? J'aurais dit bien sûr que non. Donc, on verra ce que l'avenir nous réserve.

Terry: Yes, hyper intéressant ce que tu dis. Et effectivement, sur la construction de logiciels métiers, j'ai en tête un autre épisode. Quelqu'un partageait du coup le fait qu'il y avait un profil métier justement pas du technique, il avait construit son propre logiciel métier. Alors oui, derrière le code n'était pas ouf, la manière dont c'était architecturé même n'était pas ouf, mais en fait ça répondait véritablement à son besoin et donc derrière en fait ça répondait aux besoins derrière pour la raison pour laquelle le logiciel devait exister donc il n'y avait pas de sujet au final d'architecture ou quoi, enfin ça marchait, point.

Adrien: C'est ça, aujourd'hui les avantages de faire comme ça c'est qu'on peut faire des vrais logiciels personnalisés. Pas un SaaS qui fonctionne à peu près pour tout le monde, mais tout le monde a besoin de choses un peu plus personnalisées, donc on se retrouve avec des feuilles Excel, des processus manuels. Donc on peut faire vraiment ce qui marche exactement aujourd'hui, mais si demain le processus change, on peut aussi adapter le logiciel. Et donc on n'a pas besoin de faire appel à une équipe classique avec des développeurs, on a juste une personne du métier qui peut faire son logiciel par rapport à avant. Donc ça réduit aussi les frictions, ça réduit les délais, puis il y a les coûts aussi, vu qu'il n'y a pas de coûts humains de développeurs, c'est quand même cher les développeurs. ça permet de réduire les coûts et donc du coup de faire beaucoup plus de logiciels. En fait pour moi ça fait partie de ce genre de technologie, c'est pas une question de si on est d'accord ou pas, ça va être comme ça. Ça va être comme ça parce que tout pousse pour que ce soit comme ça, et les avantages sont tellement importants que de toute manière ça va être comme ça. Donc maintenant la question c'est comment on fait pour préparer le terrain dans une DSI, dans les équipes, comment on fait pour... redispatcher les équipes sur des sujets qui vont être beaucoup plus techniques, complexes et qui vont du coup apporter aussi potentiellement beaucoup plus de valeur à l'entreprise. Et voilà.

Terry: Yes, très clair. Donc pour aller vers ma dernière question, c'est quelles sont les choses qui te nourrissent intellectuellement ? Comment est-ce que tu progresses ?

Veille quotidienne sur Hacker News, LinkedIn et les podcasts

Écouter à 51:50

Adrien décrit sa veille quotidienne, centrée sur Hacker News, LinkedIn, quelques podcasts et des vidéos YouTube. Terry lui demande ensuite quel est le meilleur moyen de le contacter, et Adrien répond : LinkedIn, sous le nom Adrien Maret.

Adrien: Beaucoup de veille. Je pense que je lis quasiment tous les jours Hacker News. Donc ceux qui ne connaissent pas Hacker News, c'est un board de news, tech. qui est poussé par Y Combinator, qui est très très vieux, qui a un design très très vieux. Mais c'est la front page of Tech Internet. Toutes les nouvelles news sont là donc voilà je lis quotidiennement. Je passe aussi du temps sur LinkedIn à lire des choses, c'est comme ça que j'apprends aussi certaines news. Je regarde pas mal de podcasts aussi. Alors non je dirais pas pas mal, je regarde quelques podcasts donc voilà j'ai commencé à regarder le tien. Je regarde un autre podcast, je peux dire le nom ? Oui, oui vas-y. On part en prod. d'Axorica. Et je regarde beaucoup de vidéos sur YouTube aussi. Mais c'est majoritairement le fait de lire des articles sur Internet, c'est comme ça que je suis au courant de ce qui se passe, en fait.

Terry: Top. Merci en tout cas pour ton partage, Adrien. Et pour les personnes qui voudraient te contacter, où est-ce que c'est le meilleur endroit pour le faire ?

Adrien: LinkedIn, Adrien Maret.

Terry: Top. Super. Merci pour ton partage et puis longue vie à Malé... Alors, je vais essayer de bien le dire, Malé... Alors, il y en a qui disent Maleus.

Adrien: Maleus

Terry: Maléus j'y arriverai pas c'est pas grave à Maléus donc via Maléus merci Terry pour l'invitation