2026.
Bonne année à celles et ceux qui lisent encore ce journal, et à celles et ceux qui tombent ici par hasard. J’ai l’impression que c’est un bon moment pour prendre un peu de recul. Pas pour faire des prédictions, mais pour nommer ce qui se passe déjà sous nos yeux, parfois sans qu’on sache très bien comment en parler.
Depuis quelque temps, j’ai le sentiment que le centre du travail logiciel se déplace. Lentement, sans annonce officielle, sans grand discours. Pendant des années, l’essentiel du métier s’est concentré sur un espace très précis. Pas dans l’idée de départ, pas dans le produit final, mais dans tout ce qu’il fallait faire entre les deux. Un espace dense, technique, exigeant, souvent invisible de l’extérieur, mais absolument central pour celles et ceux qui y travaillaient.
L’entre-deux n’est pas du management
Quand je parle de ce « milieu», ou de cet entre-deux, je ne parle pas de management. Ce n’est ni une couche hiérarchique ni une position au sein de l’organisation. C’est le cœur opérationnel du travail logiciel. Le travail de traduction. Transformer une intention en quelque chose de concret. Comprendre l’existant, configurer l’environnement, écrire, corriger, ajuster. Si tu maîtrisais cet espace, tu serais indispensable. C’est là que se jouaient le temps, l’effort et une grande partie de la valeur du métier.
Et c’est précisément cet entre-deux qui commence à s’amincir. Aujourd’hui, des systèmes sont capables de produire du code fonctionnel à partir d’objectifs, de contexte et de contraintes formulées en amont. On touche moins au code. On passe moins de temps dans l’IDE. Il devient davantage un lieu d’observation et de validation qu’un atelier de fabrication. Le code ne disparaît pas, mais le rôle central de ce milieu change.
Quand la question remonte
Du coup, la vraie question remonte. Ce qui compte de plus en plus, ce n’est pas la manière d’écrire, mais ce qu’on décide de faire écrire. Comprendre le problème réel, pas celui qu’on aimerait résoudre. Écouter ce qui vient des utilisateurs, des équipes et du terrain. Donner une forme suffisamment claire à une intention pour qu’elle puisse être exécutée sans être déformée en cours d’exécution. C’est probablement pour ça que je me reconnais dans ce déplacement.
En tant que designer UI/UX, et aussi dans un rôle de direction de projet, je passe moins de temps à produire des écrans « parce qu’il en faut », et davantage à travailler sur cette clarté. À poser les questions un peu trop tôt, celles qui simplifient tout le reste.
Tenir le cadre
Dans ce contexte, le design n’est pas une affaire d’outils ni de livrables. C’est un travail de mise au point. Clarifier ce qui compte vraiment. Poser des contraintes utiles. Accepter certains compromis, en refuser d’autres et vivre avec. Le bon travail n’est pas celui qui s’exécute parfaitement, mais celui qui mérite d’être exécuté. À mesure que cet entre-deux s’amincit, la fin du processus devient plus tendue. Quand beaucoup de choses peuvent être produites rapidement, il faut relire, tester, décider et surtout arrêter. Dire « c’est bon ».
Diriger le travail devient alors une compétence centrale. Ne pas diriger au sens de contrôler, mais au sens de créer les conditions pour que quelque chose de juste puisse émerger. Poser un cadre lisible. Partager un langage commun entre le design, le produit et la technique. Rendre les attentes claires. Quand l’entre-deux s’efface, l’intention et le résultat sont plus exposés. On ne peut plus vraiment se cacher derrière la complexité de l’exécution.
Peut-être que le métier se redéfinit là. Non plus dans la capacité à produire toujours plus, mais dans la capacité à formuler ce qui mérite d’exister, puis à reconnaître honnêtement si ce qui a été produit répond réellement à cette intention. Ce qui, au fond, a toujours été le cœur du design. On avait juste beaucoup de couches techniques dont nous nous occupions.