Florian Fesseler
Dans les deux premiers articles, on a regardé la Software Factory par le prisme du système.
D'abord en observant comment la boucle DevOps commence à évoluer vers une boucle plus autonome, dans laquelle la production et l'amélioration du logiciel ne sont plus deux sujets séparés. Puis en regardant les briques qui rendent cette factory possible : standardisation, agents en arrière-plan, sandbox, orchestration, connectivité aux outils, etc.
Mais il y a une autre conséquence, probablement plus directe pour nous : si le système change, le rôle de ceux qui travaillent dans ce système change aussi.
C'est le sujet de cet article.
Je ne vais pas essayer ici de faire une liste des compétences à apprendre, ni de prédire précisément quels profils seront les plus recherchés dans quelques années. Ce serait probablement trop ambitieux, et assez vite faux. L'idée est plutôt de regarder ce qui est déjà en train de bouger dans le rôle de software engineer, avec une vue assez court / moyen terme, disons les 12 à 18 prochains mois, au doigt mouillé.
On ne parlera pas non plus vraiment du marché de l'emploi actuel, de la question de ceux qui entrent sur ce marché, etc... qui mérite un article en soi. Ici, je veux surtout regarder le déplacement du centre de gravité.
Parce que la Software Factory n'est pas seulement un accélérateur de delivery. C'est aussi une forme de mécanisation plus poussée du métier. On le voit déjà très clairement avec la génération de code. Une partie du travail qui reposait avant sur l'exécution directe par le développeur est maintenant transférée vers des outils capables de produire, modifier, tester ou documenter du logiciel à partir d'une intention.
Plus la factory devient capable d'exécuter une partie du travail opérationnel, plus la valeur humaine se déplace ailleurs : dans la formulation des problèmes, la définition des contraintes, la conception des boucles, la supervision du système, et probablement aussi dans la capacité à faire travailler d'autres métiers avec cette nouvelle capacité de production logicielle.
C'est assez confortable à certains endroits, et beaucoup moins à d'autres. C'est ce qu'on va essayer de dérouler.
Si on simplifie un peu, le travail de développement local peut se découper en deux grandes phases. D'un côté, la recherche: comprendre un problème, explorer des solutions, debugger, construire un plan, etc... De l'autre, la production: écrire du code, ajouter des tests, documenter, faire les ajustements, etc...
Ce découpage n'a jamais été parfaitement net, mais il est utile pour comprendre ce qui est en train de bouger, parce que l'IA vient accélérer les deux.
Sur la partie production, le changement est assez visible. On écrit presque plus de code soi-même. On passe plus de temps à décrire ce qu'on veut faire, à corriger, à itérer sur quelque chose qui a déjà été généré. Même chose pour les tests, la documentation, ou certains refactorings. Tout ce qui est assez "mécanique" devient beaucoup plus rapide.
Mais la partie recherche est elle aussi accélérée. On debug plus vite. On trouve plus rapidement des pistes. On arrive plus vite à une première version d'un plan, même imparfaite. Là où on passait parfois du temps à explorer sans trop de direction, on a maintenant un point de départ presque immédiat. Ça ne veut pas dire que la réflexion disparaît (c'est tentant pourtant). Mais le temps pour arriver à quelque chose d'exploitable est largement réduit.
Et tout ça repose sur deux mécanismes assez simples.
Le premier, c'est la génération de texte, que ce soit le code ou autre chose. On délègue une partie de la production à des systèmes capables de transformer une intention en quelque chose de concret.
Le second, c'est l'accès à la connaissance.
Avant, quand tu tombais sur un sujet, un concept que tu ne maîtrisais pas, il fallait passer par plusieurs étapes: chercher des ressources, tomber sur des articles de qualité variable, essayer de comprendre ce qui est vraiment important, recouper les informations, puis reconstruire une vision cohérente adaptée à ton contexte. C'était un travail à part entière, et parfois assez long.
Aujourd'hui, tu peux directement poser ton contexte, décrire ton problème, et obtenir une synthèse déjà structurée, avec des exemples, des compromis, et souvent une première implémentation. Tu peux aussi adapter la réponse à ce dont tu as besoin : un résumé rapide, une explication plus détaillée, un schéma, quelque chose de très concret ou au contraire plus conceptuel. Ce n'est pas parfait, mais c'est déjà super-quali, c'est immédiatement exploitable et ça permet d'avancer beaucoup plus vite.
Mis ensemble, ces deux éléments accélèrent à la fois la production et la phase de recherche. Le temps pour passer d'un problème à une première solution exploitable se réduit fortement, même quand le sujet est nouveau.
Dit comme ça, ça peut donner l'impression d'un changement assez abstrait. Mais dans la pratique, ce nouveau terrain de jeu est plutôt agréable. En tout cas, il doit sûrement l'être pour tous ceux qui cherchent à résoudre des problèmes avant tout et qui ont enfin fait le deuil d'une bonne partie de leurs compétences.
On passe moins de temps sur des tâches rébarbatives. Tests, documentation, certains refactorings, ou même des choses toutes simples comme corriger des erreurs de syntaxe... tout ça devient plus fluide. Ce ne sont pas des activités qui disparaissent, mais elles demandent moins d'effort, donc on les intègre plus facilement.
Le cycle de feedback s'accélère aussi. On peut passer plus vite d'une idée à quelque chose de concret, tester, ajuster, recommencer. Le coût d'expérimentation baisse, donc on explore plus.
Et, de manière assez simple, il y a ce sentiment d'aller plus vite. Moins de friction, moins d'attente, et aussi moins de situations où quelqu'un vient te relancer régulièrement pour savoir si c'est bientôt fini. Les choses avancent plus vite, donc cette pression-là se fait moins sentir.
Jusqu'ici, on est surtout sur quelque chose d'assez positif. Mais cette évolution commence déjà à créer des déséquilibres assez visibles. Certains profils sont plus directement impactés que d'autres.
Le premier, c'est le développeur dont le plaisir est l'écriture du code avant tout. Un profil souvent très attaché à la résolution de problèmes proches de la technique, à la qualité du code en lui-même, à sa structure, à son élégance. Et parfois moins intéressé par la valeur produite derrière ou par l'impact côté produit.
Ce profil disparaît clairement et doit probablement se remettre en question fortement. Aujourd'hui, écrire du code n'est plus vraiment le point de friction principal. Dans beaucoup de cas, ce n'est même plus là que se joue la valeur. Le ratio vitesse / qualité face aux outils de génération, et à ceux qui les exploitent, est difficile à soutenir, même pour de très bons développeurs. Ce n'est pas tellement une question de niveau individuel, c'est surtout que la nature du travail change.
Il reste évidemment des cas où écrire à la main garde du sens : garder un minimum de maîtrise pour ne pas être complètement dépendant, concevoir certaines interfaces où le fait de passer par une écriture manuelle aide à mieux percevoir leur usabilité, les points de friction potentiels, et les implications des choix faits, ou simplement aller plus vite que le LLM sur des ajustements simples. Mais ça devient une partie plus réduite du travail.
Pour ces profils, il existera toujours un espace où l'écriture de code principalement manuelle garde une place importante, mais il sera fera probablement dans des contextes non lucratifs : des projets personnels, de l'open source, ou des contextes où la contrainte de vitesse et d'efficacité est moins forte.
Un effet collatéral assez intéressant, c'est la perte d'attachement au code. Quand tu n'es plus celui qui écrit chaque ligne, tu t'y attaches moins. C'est plus facile de jeter, de refaire, de repartir de zéro. On avait déjà vu ça avec le formatting automatique : moins de débats, moins d'ego sur la forme. Là, le phénomène est le même, mais à une échelle plus large. Le code devient plus interchangeable, et ça change la relation qu'on a avec ce qu'on produit.
Dans la même veine, il y a un autre type de profil qui commence à être mis sous tension : ceux qui se définissent principalement par leur stack ou par une couche technique. Le classique "Senior .NET developer", "React expert", "Backend engineer", etc.
Pendant longtemps, c'était une manière assez logique de se positionner. La complexité des outils, la profondeur des écosystèmes, mais aussi l'accumulation de connaissances nécessaires faisaient que se spécialiser pouvait avait du sens. Se former sur une stack représentait un investissement important, que ce soit pour l'entreprise, en temps de formation et d'onboarding, ou pour le développeur lui-même. Mais avec l'accès à la connaissance qui devient quasi instantané et beaucoup plus contextualisé, cette barrière-là se réduit vite. Être productif sur une nouvelle stack prend beaucoup moins de temps qu'avant. Là où il fallait plusieurs mois pour être réellement à l'aise, cette phase se raccourcit fortement. Du coup, se définir uniquement par ça devient rapidement limité.
Dans certaines expériences passées, je privilégiais déjà des profils plus généralistes, sans prérequis sur la stack technique utilisée. Le coût d'onboarding pouvait être un peu plus élevé au départ, mais il était amorti assez rapidement. Aujourd'hui, avec les outils actuels, cet amortissement est encore plus rapide.
Dans ce contexte, afficher une spécialisation forte dans son positionnement devient un signal assez faible désormais. Dans certains cas, ça montre surtout que le développeur n'a pas vraiment pris la mesure des transformations en cours.
On pousse donc assez naturellement vers des profils plus généralistes. Des profils capables de naviguer entre plusieurs stacks ou couches sans trop de friction, mais surtout capables de deep dive rapidement sur des sujets qu'ils ne maîtrisent pas, en sachant poser les bonnes questions et aller chercher les bonnes personnes pour compléter leur compréhension.
La spécialisation ne disparaît pas complètement pour autant. Elle reste pertinente dans certains cas, mais plutôt sous forme d'expertises plus profondes, souvent sur des sujets moins facilement capturables par des LLM, mais ça devient plus l'exception que la norme.
Jusqu'ici, on a surtout regardé des profils qui se retrouvent directement sous pression. Mais ça ne veut pas dire que pour les autres, le métier va rester tel quel.
Même pour ceux qui s'adaptent bien à ces changements, le rôle continue d'évoluer, et probablement assez vite. Il y a au moins deux dynamiques de fond qui sont en train de redessiner le périmètre du métier, et qui vont avoir un impact bien au-delà de quelques profils spécifiques.
La première, c'est l'industrialisation du processus de développement. Ce que j'appelle l'autonomous factory loop devient progressivement un enjeu central pour les boîtes produit. L'idée n'est plus seulement d'accélérer la production, mais de structurer une boucle complète, capable de produire, tester, mesurer et s'améliorer avec un minimum d'intervention humaine.
Cette logique n'est pas complètement nouvelle. On retrouvait déjà des préoccupations similaires dans certaines organisations avec plusieurs équipes, autour de la standardisation, de la DevEx, ou de l'outillage interne. Mais ces rôles arrivaient souvent assez tard. Dans mon expérience, il était rare de voir apparaître ce type de sujet avant d'avoir au moins 3 ou 4 équipes de développement en interne.
Ce qui change aujourd'hui, c'est que cette logique arrive beaucoup plus tôt. On ne produit plus seulement pour des humains, mais aussi pour des systèmes capables de générer, modifier et exécuter du code, ce qui demande un niveau de structuration plus élevé dès le départ.
La question, derrière, c'est de savoir si ça devient une spécialité à part entière ou simplement un prérequis pour les développeurs. Probablement un peu des deux, mais dans tous les cas, ça déplace une partie de la valeur vers la capacité à standardiser, à structurer des workflows, et à rendre le système exploitable par des agents.
On commence aussi à voir apparaître des problématiques proches de celles du machine learning : définir des objectifs, des métriques, encadrer les comportements, évaluer les résultats, améliorer progressivement le système. L'idée n'est plus seulement d'écrire du code, mais de concevoir des boucles qui peuvent tourner de manière relativement autonome.
Concrètement, ça peut prendre des formes assez simples au départ. Par exemple, l'analyse des incidents de production peut devenir une boucle en elle-même : un incident est détecté, analysé, une hypothèse de correction est proposée, testée, puis intégrée, avec un suivi pour vérifier qu'il n'y a pas de régression. Avec le temps, cette boucle peut s'améliorer, devenir plus fiable, plus rapide, et couvrir de plus en plus de cas sans intervention directe.
On retrouve la même logique sur les skills des agents. Quand un agent est capable de réaliser certaines tâches comme modifier du code, ajouter des tests, refactorer, il faut être capable d'évaluer ce qu'il produit dans la durée. Une modification peut fonctionner localement, mais introduire des régressions ailleurs, ou dégrader progressivement certaines propriétés du système. L'enjeu devient alors de construire des boucles qui permettent d'observer ces effets, de les mesurer, et d'améliorer ces skills au fil du temps.
Dans ce contexte, le rôle du développeur se rapproche de plus en plus de celui de quelqu'un qui définit les règles du jeu : quels sont les objectifs, quelles sont les limites, quelles sont les métriques qui comptent, quels types d'actions sont autorisés, dans quels environnements, avec quels niveaux de risque. Ça implique aussi des sujets plus concrets : sandboxing, gestion des credentials, sécurité, isolation des environnements, contrôle des actions des agents... toute une couche de "risk engineering" qui devient beaucoup plus centrale.
Avoir une double compétence software engineering / machine learning devient clairement un avantage dans ce contexte.
La deuxième dynamique, c'est la démocratisation de la production logicielle.
Une partie de l'implémentation devient accessible à des profils qui n'étaient pas, jusqu'ici, dans le périmètre direct de l'engineering. Et ça ne concerne pas uniquement les équipes Tech Product. On commence déjà à voir ce mouvement dans des équipes marketing, sales, ou même à des niveaux plus stratégiques.
Côté Tech Product, la barrière d'entrée baisse assez nettement. La combinaison d'outils qui simplifient l'infrastructure de base pour construire un produit, l'accès à des agents capables de produire du code, et l'accès à la connaissance font que produire quelque chose de fonctionnel devient beaucoup plus accessible.
La software factory va un cran plus loin. Elle ne se contente pas de faciliter la création de code, elle permet de le faire directement dans l'infrastructure existante de l'application. On ne parle plus seulement de prototypes isolés, mais de contributions qui peuvent s'insérer dans le produit réel, avec moins de friction et moins de handoffs.
Des profils produit peuvent montrer des prototypes interactifs directement en code, proposer des premières versions de fonctionnalités, tester des améliorations d'UI/UX, ou corriger des bugs simples sans forcément passer par une équipe engineering. Le bottleneck classique côté développement commence à disparaître sur toute une catégorie de sujets.
Pour les développeurs, ça change assez brutalement la position dans la chaîne. On est en bout de chaîne et soyez-en sûr, si une partie du travail peut être absorbée en amont, elle le sera. Il n'y a pas vraiment de raison organisationnelle pour conserver une étape intermédiaire si elle n'apporte pas de valeur claire. Ça réduit les coûts, ça accélère les cycles, et ça simplifie la structure.
Le risque, c'est donc de se retrouver progressivement dépossédé d'une partie du périmètre sans vraiment s'en rendre compte. Ça commence par des choses simples : des prototypes faits côté produit, des petites features implémentées sans passer par engineering, des corrections mineures faites directement là où le besoin apparaît. Et puis petit à petit, une partie du travail disparaît du scope des développeurs.
En parallèle, la relation au produit évolue. Ceux qui étaient déjà éloignés du business deviennent encore plus périphériques. Et même pour les autres, il y a un risque de voir certaines discussions se déplacer ailleurs. Moins de specs, plus de prototypes. Moins de cadrage en amont, plus de choses déjà "concrètes" quand ça arrive côté engineering.
Une partie du rôle des développeurs se transforme alors en un travail d'industrialisation de ces prototypes ou de fonctionnalités. Il faut les rendre compatibles avec la stack, les intégrer dans une architecture existante, gérer les contraintes de performance, de sécurité, de scalabilité.
Dans certains cas, on se retrouve à faire du reverse-engineering d'un proto pour produire quelque chose de similaire fonctionnellement, mais propre du point de vue technique. Les choix ont déjà été faits, les cas d'usage ont déjà été explorés, l'interactivité est déjà là. La partie visible et valorisée du travail a été captée en amont.
Si on reste dans cette position, le rôle se réduit progressivement à une forme d'exécution contrainte, avec moins de prise sur les décisions et moins de visibilité sur l'impact produit. La question devient donc assez simple : soit on accepte ce déplacement et on subit cette évolution, soit on s'en sert pour redéfinir sa place dans le cycle.
Parce que cette transformation ne fait pas que réduire le périmètre. Elle crée aussi de nouveaux espaces, mais ils ne sont pas forcément là où on regardait avant.
La première passe par l'acceptation que la production de logiciel ne soit plus une chasse gardée des développeurs. À partir de là, il y a un rôle à jouer pour structurer cet espace. D'un point de vue technique, ça passe par la mise en place de guardrails : définir des cadres, des conventions, des outils qui permettent à d'autres profils de produire sans créer de dette ou de rework en permanence. Sans ce cadre, une partie du travail consiste à corriger en continu des choses mal intégrées. Et assez vite, le rôle peut se réduire à retaper des implémentations bancales en boucle, sans jamais vraiment avancer. Ce n'est pas seulement un problème d'efficacité, c'est aussi une manière assez directe de se retrouver enfermé dans une partie du métier dont la valeur ne sera jamais vraiment visible.
Il y a aussi un rôle plus humain. Transmettre des réflexes, expliquer des contraintes ou des concepts, aider à comprendre comment fonctionne un système logiciel. C'est une forme de mentorat transverse qui va prendre de plus en plus de place.
L'accélération du cycle de production a un autre effet. Si la capacité de delivery augmente, il faut être capable d'alimenter ce rythme. Dans certaines situations, les équipes produit deviennent à leur tour le bottleneck.
Ça ouvre un espace pour les développeurs qui souhaitent remonter dans la chaîne et prendre une part plus active dans la définition du produit. On parle de plus en plus de convergence entre les rôles de product manager, product designer et engineer, vers des profils plus hybrides, parfois appelés "product builders". Ceux qui ne vont pas dans cette direction laisseront mécaniquement de la place à d'autres.
Dans le même temps, le coût de production logicielle baisse, ce qui remet au goût du jour certaines logiques d'internalisation. On le voit avec la remise en question de la logique SaaS et la volonté de reconstruire des outils en interne. Là où certaines entreprises faisaient le choix d'acheter, il devient à nouveau envisageable de construire. Créer devient plus accessible, mais maintenir reste un sujet. Pour certaines entreprises, il pourra devenir pertinent d'avoir un ingénieur dédié à la création et à la maintenance de cet ensemble d'outils internes, presque comme un "OS" de l'entreprise.
Dans la même logique, des rôles de support transverse peuvent émerger pour accompagner les autres équipes dans leur utilisation de ces capacités : aider à faire les bons choix techniques, éviter les dérives, structurer ce qui est produit.
Dans ce contexte, les développeurs qui avaient déjà une appétence pour les sujets produit ou business sont naturellement mieux positionnés. Ce sont souvent ceux qui peuvent s'insérer le plus facilement dans ces nouvelles zones, simplement parce qu'ils ont déjà l'habitude de raisonner en termes d'usage, de valeur et de priorisation, et pas uniquement en termes de solution technique.
Il reste malgré tout une limite assez structurelle. Sans expérience en engineering, il est difficile de construire des systèmes complexes, de gérer leur scalabilité, leur robustesse, ou certaines contraintes d'architecture. Sur ces sujets, les développeurs avec de l'expérience gardent un rôle central.
Mais cette position devient elle aussi moins confortable qu'avant. Ce qui était auparavant différenciant, savoir concevoir des systèmes, gérer la complexité, tend progressivement à devenir un prérequis. Le design de systèmes, la compréhension des architectures, la gestion des compromis techniques deviennent maintenant "table stakes". Autrement dit, ces compétences restent indispensables, mais elles ne suffisent plus à elles seules à sécuriser une position ou à se différencier durablement.
Au final, le point commun de tout ça, c'est un déplacement assez net de la valeur. Moins dans la production elle-même, qui devient de plus en plus accessible et mécanisée. Plus dans la manière dont on structure, oriente et exploite cette capacité de production.
Et selon la manière dont on se positionne, ça ouvre des trajectoires assez différentes :
Aucune de ces trajectoires n'est nouvelle en soi. Ce qui change, c'est qu'elles deviennent plus marquées, et surtout plus difficiles à éviter. Rester uniquement dans une logique d'exécution devient une position de plus en plus fragile. À l'inverse, se positionner sur ces nouvelles zones demande de faire évoluer son rôle et parfois assez drastiquement.