C’est avec le langage Ada que j’ai commencé mes études d’informatique, et c’est de loin le langage que j’ai préféré. Ce langage, qui continue d’inspirer de nombreux langages modernes, est privilégié dans les applications critiques tant civiles (aviation, train, métro) que militaires (radars, etc).


« When Roman engineers built a bridge, they had to stand under it while the first legion marched across. If programmers today worked under similar ground rules, they might well find themselves getting much more interested in Ada ! »

Robert Dewar, President Ada Core Technologies

Cette citation1 qui m’avait marqué à l’époque résonne encore plus aujourd’hui à l’heure des transformations que l’IA déclenche. J’expliquais précédemment que loin d’éliminer le développement, l’IA va au contraire élargir l’assiette d’entreprises qui investiront dans leurs propres projets, et de facto, augmentera le nombre de projets passant à l’échelle et nécessitant un travail d’ingénierie.

Une clarification de vocabulaire s’impose à ce stade. C’est Simon Willison qui apporte un éclairage dans Lenny’s Podcast.

Tout le monde s’accorde sur le « Vibe Coding » : on va vite, on ne relit pas le code, car basiquement, il n’y a pas d’enjeu. Cela peut être un outil pour soi, ou avec peu d’utilisateurs et surtout, sans conséquence en cas de bugs ou de plantages2. Tout le monde peut vibe coder désormais, avec ou sans formation d’ingénieur, et cela fonctionne bien tant qu’il n’y a pas vraiment de comptes à rendre.

Mais quand il y a un enjeu (fiabilité, sécurité, performance, scalabilité, maintenabilité, etc3.), les compétences requises pour exploiter l’IA tout en assumant une responsabilité d’ingénierie sont très différentes du Vibe Coding. Willison propose un terme que je trouve très juste : « Agentic Engineering« . Il s’agit non seulement de guider l’IA pour délivrer ce qui est attendu fonctionnellement, mais surtout de la guider pour répondre aux contraintes liées aux enjeux du projet.

Les compétences requises ne s’inventent pas. Les garde-fous et systèmes d’évaluation nécessaires requièrent autant d’apprendre les nouveaux outils agentiques que de faire appel à son expérience pré-IA de projets en production. Les ingénieurs séniors curieux et qui savent se remettre en question sont les grands gagnants de cette double exigence.

Est-ce à dire que les séniors sont protégés ? Je ne pense pas, pour deux raisons.

L’IA progresse très vite, aussi est-il légitime de penser qu’une partie des compétences évoquées feront parties des capacités de futurs modèles. À quelle horizon ? Dur de savoir tant il faut admettre qu’il est encore difficile de mettre en production les yeux fermés du code généré par l’IA (si on a les enjeux précités en tête), mais c’est probablement une question de quelques semestres.

Puis, il faut être lucide : une génération de jeunes développeurs va arriver sur le marché en n’ayant connu que le développement à l’aide de l’IA. Ils auront créé des logiciels avec l’IA, ils les auront mis en production et ils auront rencontré des difficultés (bugs majeurs, soucis de performance, difficultés de maintenance, failles de sécurité). Et c’est là que le chemin diverge : là où des séniors aujourd’hui font appel à leur expérience pré-IA, cette génération aura appris à régler ces difficultés avec l’IA et la guider pour les éviter. Dans quelques années, ils auront bâti une expertise et séniorité sur le sujet, ils feront tout autant un métier d’ingénieur et n’auront rien à envier aux séniors d’aujourd’hui.

Le métier d’ingénieur change donc, qu’on le veuille ou non. Il tend vers cette notion d’Agentic Engineering : l’orchestration d’agent permettant de délivrer, maintenir le projet, et d’assumer une responsabilité4 du projet en production sur des contraintes métiers fortes. Cela restera pour autant un métier d’ingénieur, qui ne s’invente pas 😉

  1. La citation de Dewar est réelle, l’anecdote sur les ingénieurs romains plus ou moins. ↩︎
  2. Par exemple, j’ai vibe-codé en 2h un outil permettant de gérer les présences et réunions à notre bureau en mode flex-office. Si ça plante, ce n’est pas grave… ↩︎
  3. Je pourrai ajouter la maîtrise du coût, tant la question du coût de l’IA se pose de plus en plus. ↩︎
  4. Cela vaut sur d’autres métier, je pense au Produit notamment. Quand tout le monde peut produire des spécifications en quelques minutes, qui porte la responsabilité de l’impact business ? Si la fonctionnalité n’est pas utilisée au final (manque de discovery) ou n’a pas l’impact voulu sur les taux de conversion (manque de réflexion produit), qui est responsable ? ↩︎

En savoir plus sur Kiad.org

Subscribe to get the latest posts sent to your email.