Lean, GenAI et Delivery Tech - Entretien Sylvain Fagnent : Le Lean est au coeur du sujet du Harness Engineering
Sylvain Fagnent est un des experts chez OCTO Technology sur les sujets de l’architecture des SI, des audits ou des Due Diligence techniques, et du Low Code / No Code*. Depuis deux ans, il s’est naturellement penché avec attention sur l’avènement de la Gen AI dans les processus de delivery. Il a rédigé de* nombreux articles sur notre blog sur ce dernier sujet. I**l nous a semblé un candidat naturel pour contribuer à notre réflexion sur l’intersection entre la pensée Lean et l’avènement de la GenAI dans le Delivery Tech.
Bonjour et merci pour ta disponibilité. Peux-tu te présenter et nous expliquer depuis combien de temps tu utilises la GenAI dans tes projets tech ?
J’ai démarré chez OCTO en 1999. J’ai commencé par faire du développement Java puis de l’architecture technique et de SI, essentiellement dans le monde bancaire. Depuis quelques années, je pratique des audits et les Due Diligence techniques. Vers 2015, en explorant le monde des Fintech j’ai été amené à travailler sur l’innovation dans le monde bancaire. Ce qui m’a conduit par la suite à travailler sur les démarches d’innovation et les outils Low Code / No Code. Depuis 2 ans j’ai commencé, comme beaucoup, à étudier et à écrire sur le sujet GenAI; en particulier, en évaluant son impact sur les métiers de l’IT.
Dans un premier temps, en tant que simple utilisateur, côté conseil. Puis j’ai échangé avec des personnes impliquées dans le delivery logiciel, car c’est là que l’impact est le plus fort. Je me suis demandé ce que cela allait changer à nos métiers : aux éditeurs, aux ESN comme nous, à nos clients…. Je pense que c’est une transformation dont l’impact peut être comparable à celle apportée par l’électricité à l’industrie au début du XXe siècle. Il y a de nombreuses innovations qui se bousculent et de façon très rapide. En un an, on observe une révolution dans ce qui est offert au monde du delivery. Il est toutefois nécessaire de parvenir à se projeter sans pour autant trop se noyer dans l’outillage. En échangeant avec les équipes de développement qui utilisent la GenAI, j’essaie de prendre un pas de recul pour entrevoir ce qui se dessine sur le plus long terme.
1. Accélération des phases de delivery et impact sur les organisations
Qu’observes-tu au niveau des organisations que tu accompagnes sur la mise en œuvre de la GenAI dans leur processus, et plus particulièrement sur le delivery ?
Comme souvent dans ces révolutions, on fantasme beaucoup sur ce que cela peut apporter à court terme dans les entreprises, et sur la capacité des organisations à intégrer ces pratiques. Comme j’avais déjà pu le constater, la façon qu’ont les entreprises de s’emparer des sujets d’innovation est parfois un peu hâtive : elles se projettent très vite, souvent même trop vite. Elles sont probablement inquiètes et pressées, mais avec un niveau de maturité globalement limité (hormis quelques équipes internes avant-gardistes mais isolées).
C’est ce qui s’est passé précédemment avec la digitalisation et la peur d’être dépassé par des nouveaux entrants. Tout cela remet en cause des processus existants voire des business models. Tout cela alors, qu’en interne, l’organisation ne suit pas ou freine des quatre fers. Dans le secteur bancaire, alors que certaines FinTech ont bien percé sur le marché, l’histoire montre que cela ne va pas nécessairement aussi vite que ce que l’on imaginait. D’ailleurs, même l'électricité n’a pas révolutionné la société du jour au lendemain, le processus de diffusion a été progressif [voir à ce sujet cette présentation de Eric Brynjolfsson du MIT, co-auteur de Racing Against The Machines*, sur l’impact de l’électricité sur l’industrie]*. Ces nouveaux entrants et ces nouvelles technologies permettent aux acteurs en place de se mettre à bouger, d’abord de manière maladroite, avant que quelques-uns, plus matures, montrent un chemin de transformation que les autres finissent par imiter.
Dans l’article « mettez un tigre dans votre moteur », tu évoques le fait que l’avènement d’outils tels que les Skills permettent d’accélérer de façon radicale les phases de delivery de nouvelles fonctionnalités. Quels impacts sur nos métiers d’ESN ou des DSI ?
C’est vrai qu’aujourd’hui la GenAI va beaucoup plus vite que lors de la digitalisation dans les années 2010. Certains voient une rupture. S’il y a rupture c’est avant tout sur le Business Model qu’elle s’opère. C’était mon premier article sur le sujet : comment cela va changer nos métiers au sein des ESN ? J’ai appliqué cette réflexion à ce que l’on connaissait, en partant d’OCTO qui fait du Delivery et du Conseil. Alors oui, ça va chahuter, ça va bouger mais le Business Model ne va pas complètement exploser. En tant qu’ESN, je ne pense pas que nous vivons notre “instant Kodak”. En revanche, si l’on considère des acteurs qui font du logiciel SaaS, je crains qu’ils aient beaucoup plus de soucis à se faire.
Aujourd’hui, quelqu’un qui a des connaissances pointues d’un secteur, d’un marché mais une équipe modeste en informatique peut sortir un logiciel rapidement avec des fonctionnalités qui auraient mis 6 mois à être livrées avec une équipe de 5 ou plus développeurs. Là, en un week-end, il peut parvenir à livrer des premières itérations. Le fait que ces outils permettent de faire plus de choses et plus vite qu’avant, cela vient perturber le Business Model des éditeurs en place. De même, un employé peut aussi potentiellement, en interne, développer des solutions à façon rapide pour ses propres besoins opérationnels.
Quel impact sur les rôles dans la chaîne de delivery ?
Les rôles changent : comme les tâches de réalisation sont plus “faciles”, le PM et le PO vont se concentrer davantage sur le produit, sa définition, son design plutôt que sur sa réalisation car cette partie réalisation, test, etc …, va être accélérée de façon significative. Un effet pervers: avant le rôle du PO c’était de dire “non” [cf citation de Steve Jobs]. Alors que maintenant, il peut se permettre de ne plus faire le filtre et ed proposer des fonctionnalités jugées moins essentielles parce qu’on peut les réaliser rapidement et les tester en prod. S’il n’y prend pas garde, par facilité, en limitant sa réflexion en amont, il risque de perdre sa compétence dans le design de son produit en y ajoutant des fonctionnalités sans intérêt ou incomprises par l’utilisateur.
Autre point qui émerge actuellement dans les équipes: l’accélération de la production de code grâce à la GenAI met en évidence un principe fondamental : la vitesse globale reste contrainte par le maillon le plus lent [lire à ce sujet l’entretien avec Soufiane Keli]. En augmentant fortement le débit de développement, de nouveaux goulets d’étranglement apparaissent, notamment dans les phases de revue, de validation, de test ou de mise en production. Localement on accélère mais à l’échelle du projet, sans faire évoluer l’ensemble de la chaîne, on ne va pas forcément plus vite.
>L’accélération de la production de code grâce à la GenAI met en évidence un principe fondamental : la vitesse globale reste contrainte par le maillon le plus lent. Localement on accélère mais à l’échelle du projet, sans faire évoluer l’ensemble de la chaîne, on ne va pas forcément plus vite.
Tout cela on le découvre, on apprend pas à pas, petit à petit, on apprend aussi comment on travaille avec ces outils, avec ces agents qui travaillent sur différents sujets en parallèle pour développer. On sent que le développeur va graduellement passer du rôle de Tech Lead à celui d’orchestrateur d’agents.
Le problème est qu’il s’agit de technologies non déterministes et la GenIA fait un peu comme elle a envie. Elle peut se trouver bloquée et prendre des décisions un peu radicales : ainsi la fameuse anecdote de l’IA qui a supprimé une base de données en production.
Le Harness Engineering n’existe que depuis 6 mois et son objectif est de poser un cadre et mettre des limites qui vont permettre d’éviter les écarts. Ainsi on peut mieux encadrer une technologie non déterministe. Et on remet du contrôle derrière pour s’assurer qu’on n’est pas parti dans n’importe quelle direction, en faisant quelques validations. Ex : systématiquement, tu donnes des “points de contrôle” [notons que l’utilisation des points de contrôle permettant de mettre quelqu’un en situation de valider que sa production est OK est au cœur des standards Lean]. C’est un peu comme un enfant surdoué qui peut faire des choses incroyables sans maîtrise du risque ou des dangers.
2. Éviter le chaos dans les DSI : patterns et standards d’ingénierie
Tu expliques que cette accélération peut causer un certain chaos dans les DSI : peux-tu donner quelques exemples ? Comment se prémunir contre ce risque de chaos ?
Avoir de la gouvernance en choisissant les outils, passer des gateways sur la sécurité ou l’architecture etc … Ce qu’il faut éviter c’est le shadow IT. Au début c’était avec Excel et Visual Basic puis les outils Low Code / No Code et aujourd’hui c’est la GenAI. Là, ce qui est compliqué, c’est que c’est un peu “Open Bar” pour tester des innovations ou des sujets d'efficacité opérationnelle. Pour tester rapidement une idée c’était facile avec du LC / NC, pas besoin de regarder le code car les plateformes gèrent cet aspect. L’inconvénient avec la GenAI est qu’il faut mettre dans la boucle quelqu’un qui sait architecturer, concevoir et supporter du code, car les GenAI se basent sur des modèles non déterministes : sans encadrement qui les canalisent, rien ne garantit que le code produit est maintenable ou sans faille.
>L’inconvénient avec la GenAI est qu’il faut mettre dans la boucle quelqu’un qui sait architecturer, concevoir et supporter du code, car les GenAI se basent sur des modèles non déterministes : sans encadrement qui les canalisent, rien ne garantit que le code produit est maintenable ou sans faille.
La DSI doit s’outiller pour mieux cadrer ces sujets, en utilisant elle-même l’IA. Ainsi elle peut mieux cadrer ces développements pour avoir un minimum de contrôle sur ce qui est produit afin de pouvoir garder la maîtrise de l’opérabilité et de l’évolutivité sur le long terme. On va toutefois avoir le problème du volume : on constate déjà que le nombre d’applications développées explose. La DSI doit donc s’équiper d’outils pour cadrer et valider ces nouvelles applications. A partir du moment où on fait du Build, il faut une équipe derrière pour la maintenir. Avec moins de monde qu’avant certes mais cela demeure tout de même nécessaire. L’exigence du Run ne change pas mais implique de compléter le code si besoin (observabilité, monitoring, sécurité, …).
Cela peut enlever des problèmes mais cela peut surtout en créer de nouveaux. Avant on se mettait à 5 ou 6 pour coder l’application, maintenant on n’a plus besoin que de deux développeurs. Cela a des impacts parfois très triviaux : il faut gérer plus précisément les vacances de chacun, les rituels, les rétros à 2…. La pizza team est en train de voler en éclat.
Tu évoques dans tes articles des premiers Patterns qui apparaissent. As-tu déjà pu être exposé à des projets IA sur lesquels ces patterns sont appliqués. Quels impacts as-tu pu constater ?
Je discute beaucoup avec les OCTO sur les projets de Delivery et le Harness Engineering est systématique avec l’utilisation des Skills, des agents dédiés pour faire de la vérification ; des règles dans des fichiers instructions.md avec ce qu’il faut pour “faire bien faire”.
Une autre convergence au niveau des points de vue informés est que l’IA ne fonctionne qu’avec une démarche particulièrement disciplinée, s’appuyant sur un grand nombre des pratiques d’ingénierie logicielle éprouvées. On sait que dans une grande majorité des projets tech, ces pratiques sont peu mises en œuvre car jugées trop coûteuses. Que va-t-il se passer si d’un seul coup ces projets adoptent l’IA ?
C’est ce qu’on a écrit avec Pierre-Jean Dousset dans cet article. Si tu as une organisation qui n’est pas rigoureuse et mal organisée et que tu y “injectes” de l’IA, elle va aller beaucoup plus vite dans le mur : rencontrer le chaos plus vite et plus fort [un des enseignements principaux du rapport DORA ROI Of Assisted Software Development publié au printemps 2026]. La GenAI ne transforme pas les systèmes. Elle les accélère. Et cette accélération agit comme un test permanent. Elle révèle vite ce qui tient… et ce qui ne tient pas. Notre collègue Alexandre Jeambrun me disait que le Lean va revenir très fort à la mode au sein des équipes Tech : c’est le cœur du sujet du Harness Engineering. Comme tu produis beaucoup et vite, cela peut rapidement partir dans le décor. Pour profiter pleinement de la GenAI, cela va demander davantage de rigueur, de cadrage et de harnais de sécurité.
> Le Lean va revenir très fort à la mode au sein des équipes Tech : c’est le cœur du sujet du Harness Engineering. Comme tu produis beaucoup et vite, cela peut rapidement partir dans le décor. Pour profiter pleinement de la GenAI, cela va demander davantage de rigueur, de cadrage et de harnais de sécurité.
3. L’expérience développeur au temps de la GenAI
Je constate que certains développeurs avec une fibre artisanale (les crafts) peuvent ne plus s’y retrouver dans l’évolution de leur métier et se sentent dépossédés de leur savoir faire par la GenAI. Que leur recommandes-tu ?
Ils peuvent continuer à faire le métier mais leur pratique va se déplacer. L’inconvénient est que l’on ne touche plus au code et c’est vrai que ça peut les gêner. Les Software Craftmen (artisans du code) peuvent continuer à faire le même métier en donnant des patterns, des règles de développement etc … On peut copier du code en modèle pour inciter les IA à suivre des principes de développement et de code. Du coup ils n’interviennent plus au même endroit. On peut aussi automatiser une grande partie de la revue de code avec des agents. En amont tu donnes les consignes à l’agent qui génère le code et à celui qui le revoit.
Pour faire un parallèle avec le monde de l’industrie, avant lorsque nos parents travaillaient avec des machines outils, ils faisaient un certain nombre de manipulations directement sur la machine. Aujourd’hui avec les machines numériques, il faut la programmer pour produire les pièces : le technicien ne fait plus les manipulations une à une. Une abstraction supplémentaire fait que l’espace d’intervention a évolué.
Autre analogie : le dessin industriel. Avant on travaillait avec du papier et un crayon. Puis on est passé sur des solutions numériques comme Catia et aujourd’hui on travaille directement en 3D. On produit les mêmes choses mais différemment, à travers une couche d’abstraction supplémentaire.
Enfin, c’est un peu la même chose avec les pilotes de ligne [voir cet autre article de Sylvain qui développe cette analogie]. Quand on est passé de 3 à 2 pilotes, ces derniers ont largement exprimé leur mécontentement. Si on est passé à 2 c’est parce qu’un grand nombre de commandes ont été automatisées. On pourrait passer à une seule personne mais on ne le fait pas pour assurer de la redondance. Quand il y a des changements de cette nature, cela perturbe l’organisation des entreprises et peut engendrer des impacts sociaux. Pour les pilotes cela a été plus lent car il fallait que la flotte d’avions soit remplacée.
Le changement de paradigme dans l’IT a été très rapide et a encore accéléré en 2025 avec l’avènement des agents. On trouvera toujours des exceptions dans des secteurs dans lesquels on ne met pas d’IA (médical, sécurité intérieure, nucléaire, transports) ou à la marge dans des sous domaines non risqués mais cela restera marginal. C’est toujours la même chose : tant que le gain est supérieur au risque, l’innovation va continuer. Regarde l’exemple des véhicules autonomes : en ramenant le calcul au nombre de kilomètres parcourus, ils ont moins d’accidents que les conducteurs humains.
Un sujet qui remonte fréquemment au niveau du développement augmenté par la GenAI est le sentiment de contexte switching permanent : le développeur devenu orchestrateur d’agents change sans arrêt de contexte ce qui est éprouvant mentalement. Que recommandes-tu pour éviter ce travers ?
Quand on a rédigé l’article avec Mouna sur les développeurs, nous avons eu de nombreux retours sur ce sujet du Context Switching. Ce qu’elle me disait est que le développeur apprend naturellement et va se poser des limites en évitant de lancer plus de X agents en parallèle car l’agent ira toujours plus vite et t'invitera toujours à t’engager.
Quel impact de la GenAI sur la collaboration au sein des équipes et sur la montée en compétences des collaborateurs sur la maîtrise de leur base de code ?
Le sujet est effectivement celui de la réduction des équipes et de l’impact sur la collaboration. Ce qu’on perd quand on passe de 5 à 2 développeurs c’est la capacité d’échanger avec un plus grand nombre de personnes : le dialogue est avec les agents et moins avec son voisin. Exemple avec le Poker Planning : ce n’est plus vraiment utile car l’agent est pratiquement indifférent à la difficulté. Mais si on ne pratique plus cela, on perd la partie échanges entre les différentes personnes (dev, PO…) et on risque de s’exposer à des angles morts qu’on ne voit pas et que l’IA peut ne pas voir non plus. Cela va apporter de la perte en termes d’échanges et de partage de connaissance. La question qui va alors se poser est celle de la formation de junior : comment vont-ils faire pour monter en compétence sur le métier du développement pour comprendre ce que produisent les IA [lire cet article de Andrew NG deDeepLearning.ai à ce sujet] ?
>Si on ne pratique plus le Poker Planning, on perd la partie échanges entre les différentes personnes (dev, PO…) et on risque de s’exposer à des angles morts qu’on ne voit pas, et que l’IA peut ne pas voir non plus.
Si on revient à la métaphore du pilotage d’avions, ces derniers sont pilotés avec des procédures, jusqu’au jour où on se retrouve sur un problème qui n’a pas de procédure (exemple tragique avec le drame du Paris-Rio). Une des causes est que les pilotes avaient perdu le geste, et l’intuition qui sédimente avec des heures d’expérience. L’avion était dans une posture qui ne devait pas arriver et que personne n’avait anticipée. En fait, les pilotes ne sentaient pas que l’avion décrochait, d’où dans les contre-mesures la mise en œuvre de pratique du geste par le pilotage manuel dans des situations critiques de décrochage. A contrario, dans l’exemple de Chesley Sullenberg, qui a fait atterrir l'avion sur le Hudson, il n’y avait pas de procédure. C’est l’expérience et la rapidité de décision sous stress de cet ancien pilote de chasse qui a permis de sauver les passagers.
La question essentielle qui se pose est sur la maîtrise du geste des juniors. Il est plus facile de comprendre un code tout fait plutôt que de produire le code et surmonter tous les obstacles qui vont permettre de développer une compétence approfondie. Peut-être qu’une décision sera par exemple d‘avoir des parties de code dans lesquelles on débranche l’IA et des développeurs juniors réalisent la partie correspondante d’application. [Voir cet article de Bartosz Ocytko, Engineering Manager de Zalando, qui explique comment ils incitent les développeurs juniors à coder sans l’aide de l’IA]
Une autre approche pourrait être de faire générer le code par l’IA puis de le “casser” volontairement afin d’inciter le junior à le refaire et vraiment comprendre sa mécanique interne. Si on souhaite conserver la maîtrise du code produit, il faut conserver la pratique. Comme le pilote : il pilote moins souvent mais on doit conserver la maîtrise du geste pour être capable de sentir les situations singulières et intervenir.