Lean, GenAI et Delivery Tech - entretien avec Soufiane Keli : L’IA implique que l’on soit en mode Lean sur chacune des étapes

Le préfixe Lean, GenAI et Delivery Tech identifie une série de réflexions que nous menons au sein de la practice Digital Kaizen d’OCTO Technology. L’objectif est de mieux comprendre les impacts de l’IA Générative (a.k.a GenAI) sur les processus de delivery du monde de la Tech avec un regard Lean.

Nous souhaitons ainsi proposer dans cette série des interviews, des articles de fond ou des compte rendus d’expérimentation pour essayer de mieux cerner les problèmes apportés par cette nouvelle technologie et voir comment les outils du Lean peuvent aider.

Soufiane Keli, ancien Lead Software Engineering chez OCTO Technology, nous semblait un excellent candidat pour apporter des premiers éclaircissements sur ce sujet. On peut retrouver parmi la liste des articles de blog OCTO qu’il a rédigés, des articles sur le sujet de la GenAI dès 2023.

o o o

Premières expérimentations

Bonjour Soufiane et merci pour ta disponibilité. Peux-tu te présenter rapidement et nous expliquer depuis combien de temps tu utilises l’IA dans tes projets tech ?

Soufiane, ex-OCTO et maintenant IBMer. J'utilise l’IA depuis novembre 2022, suite à la release ChatGPT 2.2. Et dans le delivery depuis 2 ans. Mais la maturité de la technologie n’était pas encore au bon niveau. Cela s’est amélioré notamment depuis Septembre 25 et GPT 5 : il y a eu une amélioration spectaculaire qui a permis l’émergence d’un certain nombre d’outils et de pratiques. La tech est alors arrivée au bon niveau de maturité pour produire du code de qualité.

Quelles sont les premières opportunités que tu as identifiées avec l’IA générative sur les processus de delivery ?

Au début, c’était plutôt sur tout ce qui concerne le fonctionnel. La tech n’était pas suffisamment mature sur le code mais sur le texte ce n’était pas trop mal. On pouvait cruncher des docs, extraire des orientations de manière industrialisée. On a tous utilisé des résumés de manière assez simple, par exemple recevoir un document client ou des spécifications de 60 pages et demander à l’IA quels étaient les messages clés : cela a grandement facilité notre travail. Au niveau du delivery c’était avec la génération de User Story. Du texte simple, sans trop de logique de dépendance. On lui donne un template de sortie et ça marche. Pour tout ce qui est normé c’est plutôt facile.

Côté code, un des premiers usages que j’ai eus sur lequel l’IA était particulièrement pertinente était l’internationalisation. Dans notre contexte, l’appli était en FR et il fallait la rendre disponible en de nombreuses autres langues. Habituellement c’est un travail qui prend un temps considérable : on doit mettre la liste de tous les champs dans un fichier Excel, avec tous les textes et labels que l’on doit maintenir dans le temps, on demande à des personnes qui parlent la langue nativement afin qu’ils traduisent pour nous renvoyer les bons labels dans leur langue.

J’ai demandé à l’équipe de créer un template (JSON) initialisé en FR et j’ai juste donné ça à ChatGPT en lui demandant de me le retourner en Italien, Polonais, Hongrois : il m’a renvoyé le bon JSON ! Il a automatiquement identifié les champs variables et non variables : ainsi les mots clés JSON n’ont pas été traduits. On l’a repris et mis dans l'application et on a commencé à supporter l’application dans toutes les langues. On a ensuite demandé aux utilisateurs de chaque pays de nous remonter les erreurs. On a divisé par cent le temps passé sur la traduction.

Quels ont été les résultats des premières expérimentations sur ces opportunités ?

À ce sujet je te renvoie au cas OCTO présenté lors de la conférence de la Duck Conf [voir la vidéo et/ou le compte rendu sur le blog OCTO]. Dans le processus de delivery, on peut gagner beaucoup par étape, d’où le lien avec le Lean.

L’enjeu clé du processus augmenté par l’IA c’est de conserver un facteur de gain important de bout en bout du flux de production, et cela est très difficile [NDLR : voir cette étude du MIT à ce sujet, étude qui confirme exactement ce qu’évoque Soufiane, à savoir que plus on va en aval dans le processus de delivery, plus les gains réduisent de façon spectaculaire]. C’est pour cela qu’il faut être en “mode Lean” sur toutes les étapes. On ne peut malheureusement pas faire la somme des optimisations locales !

On peut gagner x100 sur la génération de code, c’est facile. Sur la revue, le x100 va vite se transformer en x20. Et puis, quand je vais passer la main aux tests, s‘ils ne sont pas automatisés, les x100 devenus x20 vont devenir x10. Et puis il y a les OPS où là encore on peut voir des goulets [voir cet étude de Harness.io à ce sujet].

Quels ont été les premières difficultés rencontrées sur ces cas d’usage ? Comment avez-vous traité ces obstacles ? Quels ont été les premiers enseignements et comment avez-vous fait évoluer vos pratiques pour les prendre en compte ?

Au tout début, la génération n’était pas bonne. Quand on demandait de faire une application, le modèle n’arrivait pas à avoir une continuité entre le code qu’il a généré au début du projet et celui qu’il produit plus tard. Exemple : il n’invoquait pas le nom de méthode qu’il avait défini pour aller récupérer un objet métier. L’implémentation de la mémoire sur les LLM a permis d’adresser ces sujets là.

La clé pour éviter la confusion est de diviser ce qu’on demande en petites parties. On subdivise en petites parties très circonscrites, ce qui permet au LLM d’être plus pertinent. Un Context Window d’un million de tokens ne sert à rien, 200.000 suffisent. Et l’humain est moins fatigué : il a moins de contexte à conserver à l’esprit lui aussi. C’est une habitude fondamentale dans l’usage de la GenAI. Si tu lui demandes d’écrire un article ou un bouquin cela ne va pas avoir le même niveau de qualité. Et puis pour un livre, la tâche de relecture sera colossale. En revanche, si tu lui demandes de générer deux pages par deux pages, cela sera plus simple pour toi comme pour la machine. Il faut de la méthodologie pour nourrir le contexte pour que la structure globale puisse s’y référer à bon escient et se tromper moins. L’humain qui doit rester en contrôle et ne pas s’y perdre non plus.

“La clé pour éviter la confusion est de diviser ce qu’on demande en petites parties. On subdivise en petites parties très circonscrites, ce qui permet au LLM d’être plus pertinent.”

Tu évoques dans la vidéo de la Duck Conf le déplacement des goulets d’étranglement. Cela rejoint un constat fait par Harness.io sur les impacts sur les équipes OPS. Comment l’avez vous traité dans votre projet ?

On l’a géré en créant de la relation humaine avec les métiers et en montrant plus fréquemment la valeur aux métiers. On l’a résolu en phase d’UAT. Au début, on était dans une refonte et on était autonome pour comprendre l’existant [On retrouve la perspective de Loïc Le Floch (qui a mené cette mission avec Soufiane) sur le podcast d‘Antoine Mazure]. En UAT il y a avait des demandes supplémentaires à implémenter. Le métier a fait un Workshop et on n’a pas tout compris. Aussi, on leur a proposé de changer la méthode :

1. Vous nous expliquez précisément ce que vous attende ;
2. On code rapidement ;
3. Vous nous donnez votre feedback.

[Dans le podcast précité, Loïc ajoute que l’on jette le code (sic !) généré précédemment car celui-ci ne représente qu’un coût négligeable à reproduire]

Sur certains sujets très compliqués, au lieu de passer énormément de temps à cadrer, on s’est assis à côté d’eux avec un petit brief. On pourrait presque s’affranchir de la création de specs, si le LLM n’en avait pas besoin :-)

Gestion des tokens

Parlons de la gestion du coût des tokens. Celui-ci a vécu une augmentation exponentielle durant les dernières semaines. Tu expliques dans un de tes articles qu’aujourd’hui cette évolution de coût est imprévisible et que les DSI doivent la piloter au trimestre : comment expliques-tu ce caractère imprévisible ?

Ce caractère imprévisible est dû au contexte des fournisseurs : un certain nombre d’entre eux va faire des IPOs : il faut qu’ils montrent des chiffres positifs, en amélioration. On sait tous qu’ils sont déficitaires. En tant que DSI je sais que je ne les achète pas à un prix qui correspond à leurs investissements et infrastructures. Depuis le début, on sait que des milliards sont investis pour créer les Data Centers et qu’ils vendent leur produit à perte. En tant que DSI je les achète moins cher que leur valeur de production. Je ne peux pas planifier sur le long terme en prenant pour base ce prix car je vais prendre un retour de bâton.

La clé est qu’il faut mesurer le nombre de tokens consommés : c’est de la matière première, cela doit être contrôlé. Je ne suis pas expert Lean et je me nourris beaucoup d’analogie entre usine produit et usines logicielles pour trouver des solutions. Les gens ont déjà réfléchi au sujet.

Une pratique que les DSI doivent faire : des Gemba Walks pour aller voir les développeurs et leurs pratiques de développement. Pareil pour les architectes d‘entreprise, ils ne peuvent pas rester dans leurs bureaux. Sinon ils perdent de la crédibilité et ne sont pas en situation de prendre des décisions bien informées. L’IA a plusieurs niveaux de maturité : elle peut aider (auto-complétion) ; elle peut prendre quelques tâches ; elle peut enfin être autonome et fabriquer le logiciel en tant que Software Factory, comme une usine TESLA.

“En tant que DSI j’achète les tokens moins cher que leur valeur de production. Je ne peux pas planifier sur le long terme en prenant pour base ce prix car je vais prendre un retour de bâton.”

Tu proposes dans une série de quatre articles sur la gouvernance IA (1, 2, 3, 4) une réflexion sur la gestion des coûts de tokens, et tu évoques une stratégie d’optimisation avec de nombreux outils. Ce sujet semble devenir un sujet clé à part entière dans les organisations tech. Quelle est ta recommandation pour construire une stratégie efficace sur ce sujet ?

Le premier point, je l’évoque dans le dernier article : il faut que le prix soit connu pour être intégré dans le coût de fabrication. Le deuxième point est celui du principe show back, charge back. Il est nécessaire de savoir combien tu consommes. Dans mon IDE je peux voir quel est mon budget mensuel et le suivre. Le fait de le rendre visible responsabilise les personnes. Avant les gens s’en moquaient. Maintenant même Claude le montre.

Aujourd’hui je peux même voir la consommation générale de mon équipe. Ainsi, en tant qu’Engineering Manager, je suis capable de suivre la consommation budgétaire de mon équipe et implémenter le mécanisme ChargeBack avec lequel les dépassements sont directement facturés au projet de l’équipe : et là ils vont y porter plus d’attention. Et puis il y a les outils pour optimiser avec des caches, du batch etc …. Il est nécessaire de documenter et d’expérimenter avec ces outils. Le point clé demeure la responsabilisation des collaborateurs dans leur consommation de cette “énergie” et de cette “matière première”.

“Le deuxième point est celui du principe show back, charge back. Il est nécessaire de savoir combien tu consommes. Dans mon IDE je peux voir quel est mon budget mensuel et le suivre. Le fait de le rendre visible responsabilise les personnes.”

Tech, IA et manufacturing

Tu évoques souvent le monde de l’industrie dans tes analogies, qu’est-ce que le monde du logiciel peut apprendre de l’industrie ?

En effet je m’inspire du monde industriel. Regardons un peu ces industries qui ont plus d’une centaine d’années d’existence. Il y a des enseignements à retirer. Jusqu’à maintenant le logiciel était une industrie à part, avec un mode agile qui était une façon d’absorber l’incertitude autour de la construction de produits numériques. On entre dans l’ère industrielle du logiciel avec des agents qui sont comme les robots dans les usines. Tu ne peux pas venir les programmer avec des consignes approximatives : elles doivent être précises, normées.

Par exemple : je fabrique une pièce dans ma chaine. Si j’ai une pièce défectueuse, le contrôle qualité l’identifie et la sort de la chaîne. Dans une usine Lean, tu arrêtes la chaîne de production. Dans le logiciel il faut que cela soit pareil : tu fais le code et lance les tests et là on voit un défaut. Comme le code a été construit avec des agents (robots avec instruction) il faut s'arrêter, revenir en arrière et corriger l’agent avec les bons skills, contextes et harnessing.

Si, en tant que DSI, je construis un produit en utilisant de la GenIA dans le processus de réalisation, il faut que j’en connaisse le prix. Quand Renault fabrique une voiture, ils ont bien à l’esprit le cours de l’aluminium ou du cuivre : cela va influencer directement le coût de revient du véhicule.

La GenIA doit être considérée comme de l’énergie ou de la matière première [lire l’article dans lequel Soufiane développe cette idée] . Ce coût fluctue sur le marché, il est soumis à des tensions géopolitiques (ex : l’accès à Fable 5 a été coupé par le gouvernement américain). Imagine que Trump coupe l’accès des entreprises étrangères à Claude Opus ou Sonnet …

IA, Innovations incessantes et avenir des professionnels de la Tech

Nous constatons une accélération vertigineuse de l’innovation liée à la GenAI dans les outils et pratiques sur ces douze derniers mois, accélération que tu évoques dans ta présentation à la Duck Conf. Quel est ton point de vue : penses-tu qu’il s’agisse là d’une phase de lancement qui va ensuite se stabiliser avec des innovations incrémentales ou qu’il s’agit là de notre destin sur cette discipline : des incrémentations radicales incessantes ?

Je te donne un exemple. Dans la littérature sur l’innovation, on fait souvent référence à l’avènement de l’électricité. A cette époque on ne savait pas encore ce qu’on allait faire avec, on n’anticipait pas les multiples applications qui allaient apparaître [voir dans Race Against The Machines de Brynjolfsson et Andrew McAfee cette observation selon laquelle les gains économiques ne sont apparus que 30 ans plus tard]. Même chose avec l’avènement d’Internet.

L’IA est apparue il y a longtemps mais pour la GenIA c’est plus récent. Je pense que c’est parti pour impacter de très nombreux domaines métiers. Chez IBM nous disposons d’un grand nombre de modèles Fondation dans des domaines métiers différents : biochimie, spatial, géoscience (extraction minière), polymères [voir cette présentation de Arthur Mensch CEO de Mistral qui évoque les nombreux potentiels d’innovation grâce à l’IA sur ces sujets scientifiques hors-tech]… Regarde le nombre de vulnérabilités trouvées par Mythos et l’impact sur Chrome par exemple : ils sont passés de 50 bugs corrigés par mois à 200 ou 300.

Aujourd’hui on parle beaucoup des agents et de leur feedback loop qui vont leur permettre de soulager la charge de revue par les humains. Tu donnes une liste de vérifications à l’agent qui va lui permettre de valider son travail. Il produit, vérifie, et peut se rendre compte qu’il a mal fait les choses : il reprend et il corrige. Et il t’expose ce qu’il est en train de faire. Tu peux être explicite dans ton prompt en lui demandant de vérifier l’output avant de reprendre la main.

Au-delà de certains développeurs qui se sentent dépossédés de leur dignité de crafts, l’avènement de la GenIA cause une certaine appréhension dans les métiers de la Tech et sur la pérennité d’une carrière dans ce domaine. Quel regard portes-tu sur cette situation ?

On a une staffing manager qui nous a expliqué qu’on automatisait le processus de staffing. Elle nous a expliqué qu’elle envisageait de créer les agents qui allaient la remplacer. Il est probable que l’on va se passer de certaines personnes. On va créer de nouvelles opportunités et est-ce que tout le monde sera capable de les prendre ? Je ne sais pas.

Sur la partie Tech, on crée de la demande. On a encore besoin de monde. On cherche des gens d’un nouveau genre, ceux qui savent bien utiliser l’IA. On est en train de créer des agents qui réduisent le nombre de développeurs dont on a besoin. Et ensuite on se trouve face aux stratégies d’entreprise : est-ce qu’on va se dire que l’on garde l’ensemble des développeurs pour livrer plus de valeur avec le même budget ? Où se dire que l’on réduit le budget et que l’on se sépare des collaborateurs ?

On aura toujours besoin de software engineers, on n’arrivera pas à les supprimer intégralement, ce n’est pas possible. On aura besoin de gens plus pointus que ceux que l’on avait avant. Il y a un déplacement de la valeur vers l’architecture, les spécifications, le produit. Et là tu as deux types de population : ceux qui aiment écrire du code qui se sentent dépossédés de quelque chose qu’ils aiment faire et les autres. Personnellement j’aime écrire pour extérioriser mes pensées avec un style : j’écris parce que j’aime ça. J’utilise l’IA pour corriger, mais je n’ai pas besoin d’être assisté. Quand un peintre ou un musicien fait de l’art, il ne va pas utiliser un robot. Il y a des gens pour qui le code est un processus créatif et pour eux, en effet, c’est une hérésie. D’autres voient la production de code comme un métier et utilisent les outils à disposition. Cela va dépendre du lien fondamental qu’entretiennent les devs avec le code.

Soufiane, mille mercis pour cette perspective éclairée et bonne continuation !