Le renouveau de l'Analyste Programmeur ?

En 2003, je suis sorti d’IUT avec mon DUT d’ingénierie logicielle en poche et avec le titre d’Analyste Programmeur.

Et pendant les années suivantes, peut-être même pendant la moitié ou les deux tiers de ma carrière, j’ai fait beaucoup de programmation et assez peu d’analyse.

Trois ans plus tard, j’approchais de mon Master et ma première mission en stage de fin d’études était d’implémenter ce qui était décrit dans un document de Spécifications Techniques Détaillées de plusieurs centaines de pages. Je devrais plutôt dire : de réécrire ce document, sous forme de code¹. Sans blague !

Ce document était d’ailleurs lui-même basé sur un autre document : les Spécifications Fonctionnelles Détaillées.

Autrement dit : un Chef De Projet Fonctionnel avait parlé avec le client, avait étudié son besoin, l’avait transcrit dans un premier document. Puis un Chef De Projet Technique avait étudié ce document fonctionnel et l’avait traduit dans un second document technique.

Enfin, en tant que stagiaire Ingénieur Concepteur et Développeur, mon seul rôle était de prendre des phrases en français et de les réécrire dans un langage de programmation².

Heureusement, au fil des années et des postes et des projets, mon rôle a bien évolué.

Bien des années plus tard, j’ai rejoint une entreprise où des développeurs et développeuses recevaient des User Stories leur disant quoi faire… J’étais parfois surpris de lire « il faut développer X de telle manière, puis il faut faire Y de telle façon et enfin il faut faire ça comme ça ».

Je veux dire : si je recevais une carte me disant comment implémenter une fonctionnalité, quelles classes voire quelles méthodes écrire, quel moteur de base de données utiliser, quelles tables créer et quelles informations cacher ou non… J’aurais le sentiment qu’on a déjà fait le gros du boulot et qu’il ne me reste plus qu’à écrire le code avec un langage de programmation, à partir des instructions en langage naturel !

Toutefois, pour certains devs dans cette entreprise, parfois pour des gens un peu juniors ou un peu renfermés, « tu n’auras pas besoin de parler aux clients » était un argument lors du processus de recrutement.
Et pour l’entreprise, elle avait peut-être l’impression d’optimiser, avec des Product Owners qui parlaient aux clients, des Tech Leads qui écrivaient des spécifications techniques, et des développeurs qui écrivaient du code ?

En parallèle, quand je disais « ton rôle est que ça marche : à toi d’aller voir qui il faut pour comprendre le besoin, pour réfléchir à quoi faire et à comment l’implémenter — tout en t’aidant de l’équipe et de moi » à une nouvelle recrue dans l’équipe DevOps dont j’étais Lead, j’avais l’impression qu’on ne vivait pas dans le même monde…

Avance rapide de quelques années à nouveau. Depuis 2025 et surtout début 2026, je vois de plus en plus de développeurs et de développeuses suivre une approche « spec-driven » et commencer par écrire des spécifications. Ou plutôt, commencer par coécrire des spécifications avec leur agent — qui est donc bien plus qu’un agent de codage. Et je vois ces mêmes devs passer moins de temps, parfois bien moins de temps, à écrire du code.

Presque 25 ans après avoir obtenu mon diplôme d’Analyste Programmeur, j’ai l’impression que, enfin, la partie analyse du métier revient sur le devant de la scène³ : comprendre les besoins des utilisateurs, réfléchir à quoi implémenter, avant de commencer à coder !

Avec les outils qui en font de plus en plus sur la partie programmeur et avec l’écriture du code qui prend désormais moins d’importance, ce sont peut-être enfin les phases d’analyse et de conception qui vont (re)devenir primordiales ? Encore plus qu’hier, ce sont elles qui vont déterminer si les logiciels que nous créons répondent enfin aux attentes de leurs utilisateurs 🙏.

Illustration par Kelly Sikkema sur Unsplash