Tribunes

L'ingénierie logicielle à l'ère de l'IA : tout change... et rien ne change

Olivier Rafal, consulting director strategy de Wenvision : « tous ces relâchements que le rythme humain absorbait tant bien que mal deviennent, à la vitesse de l'IA, des défauts industriels ». (Photo : D.R.)

L'IA bouleverse la fabrique du logiciel : rôles, équipes, modèle opérationnel, tout est à repenser. Mais le cycle de développement lui-même, finalement, ne change pas vraiment - il exige au contraire une discipline accrue. Olivier Rafal décrypte ce paradoxe et ses conséquences pour les DSI.

PublicitéPosez la question à n'importe quelle équipe de développement aujourd'hui et vous obtiendrez la même réponse, mi-enthousiaste, mi-inquiète : « tout est en train de changer. » C'est vrai. Un agent IA produit en quelques heures ce qu'un ingénieur livrait en plusieurs jours. Les product owners (PO) peuvent coder eux-mêmes leurs prototypes. Votre CEO peut vibe-coder votre nouveau site web en un week-end. Les rôles se redéfinissent, les organisations se reconfigurent, le métier de développeur change drastiquement.

Et pourtant. Quand on considère non pas la production de code, mais le cycle de vie du logiciel - le SDLC (software development life cycle), qui va de l'idée jusqu'à la mise hors service du produit - un constat s'impose : rien ne change. Il faut toujours définir avant de construire, vérifier avant de livrer, exploiter avant de faire évoluer. L'IA n'abolit aucune de ces étapes. En revanche, elle les rend plus exigeantes.

Ce changement dans la continuité n'est pas un jeu de mots. C'est, je crois, la grille de lecture la plus utile pour un DSI qui veut passer d'une adoption par quelques développeurs enthousiastes à un cycle de développement augmenté à l'échelle. Nous l'avons vécu de l'intérieur chez Sfeir, en nous appliquant à nous-mêmes la transformation que nous accompagnons désormais chez nos clients. C'est donc un retour terrain que je vous livre.

Ce qui change vraiment : le modèle opérationnel

L'erreur la plus répandue consiste à traiter l'IA comme une couche d'outillage qu'il suffirait de poser sur le cycle existant. Un copilote pour les développeurs, et on passe à autre chose. C'est une erreur à plusieurs titres. D'abord parce que se contenter d'un assistant de code à l'heure des agents, c'est partir avec un handicap. Ensuite parce que chercher à augmenter la productivité des développeurs, c'est bien... mais ça ne fait pas tout.

Les gains n'apparaissent pas tout seuls par magie. Les développeurs doivent être accompagnés, il leur faut acquérir de nouveaux réflexes, de nouvelles compétences. Et il ne faut pas s'arrêter là : dès lors qu'on augmente le développement, le goulet d'étranglement se déplace : la spécification en amont et la validation en aval deviennent des facteurs limitants.

Avec l'agentique, chaque rôle de la chaîne change de nature. Le PO ne découpe plus un backlog en tickets, il produit du contexte exploitable par l'IA. Le développeur n'écrit plus le code : il cadre, oriente et révise l'exécution de ses agents. Le QA (Quality Assurance, l'ingénieur chargé des tests et recettes), souvent relégué en bout de chaîne, a une nouvelle opportunité de définir en amont les preuves attendues. Et ainsi de suite pour tous les métiers.

Si un seul de ces rôles ne suit pas le mouvement, l'organisation entière reste calée sur la vitesse du maillon le plus lent. C'est pourquoi le sujet n'est pas un sujet d'outil, mais un sujet de modèle opérationnel - autrement dit, de TOM (Target operating model) agentique.

PublicitéCela va jusqu'à la forme des équipes. Nos amis américains, prompts à labelliser les concepts, ont déjà acté la fin des "double pizza teams" au profit des "sandwich teams". Finies les équipes de huit personnes qui se passaient le travail de main en main, du PO au BA (Business Analyst), du dev au test, du test à l'Ops. Voici le temps des binômes resserrés, expert métier et tech lead augmenté, l'IA en exécution et d'autres compétences en support de manière plus ponctuelle

Chez nous, ce binôme pilote désormais environ 80% de la chaîne de production ; les 20% restants (architecture, gouvernance des données, sécurité) restent centralisés. Moins de relais, plus d'ownership, des périmètres plus larges par personne. Voilà le vrai chantier : il est organisationnel et culturel davantage que technologique.

Ce qui ne change pas : le cycle et sa discipline

L'IA accélère tout. Beaucoup en concluent qu'elle permet de sauter des étapes, qu'on peut désormais aller du désir au logiciel en court-circuitant la définition, la planification, la revue. En ce sens-là, il est évident que le vibe-coding ne serait pas soutenable pour un logiciel d'entreprise. Le développement agentique en entreprise est très éloigné de cette définition. Un cycle de développement reste un cycle de développement : les phases sont les mêmes, ou presque, et elles ne sont pas négociables. Ce qui change, c'est le coût de l'indiscipline.

Quand on écrit le code à la main, une spécification approximative va se payer par des allers-retours, lents, mais qui laissent le temps de corriger le tir. Quand une IA produit le code, la spécification approximative se traduit instantanément par des milliers de lignes de code qui partent dans la mauvaise direction. L'imprécision se propage désormais à la vitesse de la machine. Le test négligé, la revue expédiée, la décision d'architecture non documentée : tous ces relâchements que le rythme humain absorbait tant bien que mal deviennent, à la vitesse de l'IA, des défauts industriels.

Pensez à la différence entre le sport amateur et le sport professionnel : dans le premier cas, un petit manque de préparation physique ou un écart alimentaire n'ont pas une grande importance ; dans le second, c'est impardonnable. En d'autres termes : plus l'exécution est rapide, plus le cadre doit être strict. Il faut poser un framework qui décrit les étapes adaptées à votre contexte, avec sa traduction concrète en règles agentiques, qu'on appelle un harnais.

Dans notre propre cycle, cela s'est traduit par un petit nombre de "gates", des étapes de contrôle humain inviolables - la spécification, le plan, la revue de la livraison - sur lesquelles nous sommes intraitables, tout le reste étant exécuté par les agents. Cela signifie une discipline de preuve : on valide la sortie réelle, mesurée, pas la parole de l'IA qui affirme volontiers que tout fonctionne. Cela signifie aussi capitaliser systématiquement, faire en sorte que chaque cycle livré enrichisse le suivant ; après une dizaine de cycles, nous avons mesuré une baisse d'environ 30% des itérations de correction - la capitalisation paie, par construction.

Rien de tout cela n'est nouveau. Ce sont les fondamentaux du génie logiciel. L'IA ne les invente pas ; elle les rend non négociables.

Gouvernance, FinOps, pilotage par la valeur : la troisième jambe

Cette exigence de discipline ne s'arrête pas aux portes de la fabrique du code. Elle doit remonter jusqu'au pilotage, et c'est une dimension trop souvent oubliée.

L'IA d'entreprise a un coût récurrent, variable, et il faut l'assumer. La bascule de nombreux outils vers la facturation à l'usage en est le signal le plus net : l'IA n'est plus un forfait, c'est une ressource de production, comme le cloud l'est devenu dans les années 2010. Un poste de travail augmenté représente aujourd'hui de l'ordre de 10 € de l'heure et par personne. Un chiffre qu'il faut comparer non pas à zéro, mais au coût horaire chargé d'un ingénieur. La bonne nouvelle, c'est qu'un coût variable est un coût pilotable : attribuable par équipe, par cycle livré, optimisable. Comme pour le cloud, le bon réflexe face à la consommation n'est pas d'interdire ou de plafonner, mais de rendre le coût visible. C'est du FinOps appliqué à l'IA.

Ce qui me donne l'occasion de tordre le cou à un autre contresens courant : le FinOps est une discipline qui consiste non pas tant à réduire les coûts qu'à optimiser l'efficience des outils. Quel intérêt y aurait-il à mettre en place des mécanismes savants de réduction de consommation des tokens pour payer moins cher si on ne se préoccupe pas de ce qui est effectivement livré ? Il faut considérer le coût rapporté à la valeur livrée - qui ne se mesure pas en nombre de lignes de code. C'est l'un des aspects les plus complexes dans le cloud, qu'on retrouve ici aussi, parce qu'il touche non pas à la technologie, mais à la stratégie produit. Piloter par la valeur suppose en effet de s'être calé en amont sur un certain nombre de métriques business ; qu'est-ce qui est privilégié : le time to market ? le nombre de features ? la performance ? l'écoconception ?

Pour un DSI, adapter sa SDLC à l'agentique nécessite d'abord une élévation culturelle transversale ainsi qu'une certaine introspection : la relation avec le business permet-elle ce pilotage par la valeur ? est-on collectivement capable de respecter une discipline stricte ? Faute de sécuriser ces aspects, une SDLC dopée à l'IA ne fera qu'amplifier les problèmes et vous aidera juste à aller plus vite... dans le mur.

Article rédigé par

Olivier Rafal, Consulting Director Strategy de WEnvision
Olivier Rafal est Consulting Director Strategy de WEnvision, cabinet de conseil du groupe SFEIR. Consultant, auteur, conférencier, formateur, Olivier Rafal a rejoint SFEIR en 2020 et cofondé WEnvision en janvier 2022.

Ancien rédacteur en chef de lemondeinformatique.fr, Olivier Rafal a ensuite passé 10 ans dans un cabinet de conseil et d'analyse du marché IT. Il accompagne aujourd'hui les entreprises tout au long de leur démarche de stratégie numérique et de modernisation des SI, toujours dans l'optique de la création de valeur.

Olivier est ainsi l'interlocuteur privilégié des CIO et CTO pour co-construire et formaliser leurs feuilles de route, cadres de gouvernance et grands principes directeurs, ainsi que les documents et business cases requis pour expliquer la démarche aux Comex et fonds d'investissement.