Le développeur avec IA est un mouton à 5 pattes

« Notre développeur idéal, c'est un mouton à 5 pattes. » C'est comme ça qu'on résumait, il y a quelques années, le profil qu'on voulait recruter. Mi-blague, mi-aveu : on savait qu'on demandait beaucoup, on le demandait quand même, et on trouvait des gens pour le faire.

Ce qui était une originalité de notre recrutement est probablement en train de devenir la norme du secteur. On le faisait déjà, l'IA est simplement en train de le rendre obligatoire.

On le faisait déjà

Depuis qu'on fait ce métier, on exige de nos développeurs qu'ils décentrent leur regard. Qu'ils ne se contentent pas d'écrire du code qui marche, mais qu'ils comprennent pourquoi on l'écrit, pour qui, à quel coût, et dans quel rythme. C'est-à-dire qu'on leur demande de porter plusieurs visions différentes, parfois dans la même journée. Cinq pattes, donc (en réalité plutôt six, mais vous avez l'idée...) :

Une vision produit. Parler au client, être force de proposition sur l'amélioration globale de la solution. Savoir dire : « vous allez faire une bêtise, on peut vous proposer un raccourci qui fera l'affaire pour trois fois moins de temps et de budget. »

Une vision gestion de projet. Se situer dans l'organisation générale, anticiper les temps des autres, livrer en fonction des rythmes de chacun. « J'ai travaillé en priorité sur ce module qui vous posait problème pour vous permettre de le tester pendant votre semaine de recette ; pendant ce temps je reprends les tâches moins urgentes. »

Une vision utilisateur. Se préoccuper de l'usage réel de l'outil, pas seulement de son fonctionnement technique : ergonomie, usabilité, accessibilité, UX. « J'ai relu les spécifications et la maquette que vous proposez n'est pas logique dans le parcours utilisateur, je vous propose de la modifier ainsi… »

Une vision budget. Jauger le niveau d'approfondissement technique en fonction des attentes du client, éviter la suroptimisation de performance. Tout n'a pas besoin d'être taillé pour supporter dix millions d'utilisateurs quand la base en compte trois mille, et le dev qui le sait économise des semaines de travail pour rien.

Une vision process. Implémenter les workflows de contrôle qualité (sécurisation, conventions, monitoring) et l'automatisation du déploiement, pour industrialiser le contrôle plutôt que le subir à la relecture. Un pipeline de tests qui tourne seul vaut mieux que dix allers-retours de validation à la main.

Une vision marketing/communication. Intégrer la diffusion du projet en aval du développement : SEO, marketing, landing pages, tracking. Un site qui n'est pas trouvé est un site qui n'existe pas, et le dev qui l'écrit est bien placé pour le savoir, puisqu'il a les mains dans le code au moment où les balises se décident.

Pourquoi tout demander à un seul profil

On aurait pu créer des silos. Mettre un UX d'un côté, un chef de projet de l'autre, un expert SEO à l'occasion, un référent sécurité les jours de grande peur. On ne l'a pas fait, et ce n'est pas par économie.

On a vu ce fonctionnement en silo dans d'autres équipes. On a vu des développeurs détendus, peu impliqués dans l'usabilité de leur interface (« c'est pas moi qui fais l'UX »). On a vu des chefs de projet faire de la rétention d'information et dire au client « je ne sais pas comment ça marche, faudra que je transmette votre demande à un DevOps ».

Si on a fait un choix radicalement différent, c'est pour limiter le nombre d'interlocuteurs et garder des équipes compactes de gens pleinement focalisés sur la réussite. Plus besoin de « passe-plats », ces responsables de projet qui servent uniquement à parler au client pour répéter, avec des erreurs, à l'équipe technique ce qui s'est décidé. Chacun a l'info en direct, et comprend les enjeux.

Plus besoin non plus de mobiliser un expert de chaque domaine quand les devs ont un périmètre d'action suffisamment large pour gérer en solo 90 % des demandes courantes. On a toujours besoin d'experts à certains moments clés : un UX-UI en phase de conception, puis un expert SEO pour donner la stratégie. Mais au quotidien, les devs font le boulot.

Le mouton à 5 pattes, ce n'est pas un profil par défaut. C'est un choix d'organisation : on préfère quelques gens qui voient large à beaucoup de gens qui voient étroit.

Comment ça s'est traduit chez nous

Ce choix s'est déposé, année après année, à différents étages de la boîte.

Au recrutement. Les profils n'étaient pas seulement évalués sur leurs compétences techniques, mais de plus en plus sur les à-côtés. On disait qu'on cherchait des moutons à 5 pattes, ce n'était pas toujours facile mais cette exigence s'est révélée un facteur de qualité.

Dans la constitution des équipes. Le modèle idéal, c'est la team de 2 à 3 développeurs. On évite le dev solo, qui devient une personne clé et un risque dès qu'il part en congé ou en démission. On préfère la redondance, et on préfère surtout une équipe qui se parle et confronte ses idées, et qui parle en direct au client, parce que c'est hyper efficace.

En 2024, en séminaire, on l'a abordé sous l'angle de l'empathie. Des exercices pour se mettre à la place du product owner, du responsable de budget, du chef de projet. L'idée : comprendre l'univers mental et les problématiques de leur interlocuteur quotidien, pour apporter de meilleures réponses, voire anticiper les demandes.

En 2025, on l'a résumé sous le terme d'ownership (certains parlent de captainship : chaque moussaillon doit avoir la capacité à prendre les commandes même quand le capitaine s'absente). On a fait une cartographie des sujets qui tournent autour du dev, de l'amont (conception, UX…) à l'aval (maintenance, com…).

L'IA le rend obligatoire

Ça fait résonance avec un post LinkedIn récent de Thomas Sérès, CTO chez Théodo. Il reprend un schéma Gartner 2026 qui dit ceci : Product Manager, Software Engineer, Designer/UX, QA, Scrum Master, Business Analyst, Architecte, DevOps/SRE, Data Scientist, ML Engineer… tout ça converge vers trois familles.

→ Product Engineers
→ Forward-Deployed Engineers
→ AI Platform Team

Et il ajoute : « Si vous êtes développeur aujourd'hui, vous serez sans doute Product Engineer demain. Donc apprenez le design, l'UX, le QA, le produit. Concentrez-vous sur l'utilisateur plutôt que sur la syntaxe. » Et surtout : « L'IA est peut-être simplement en train de le rendre non négociable : quand l'écriture du code coûte moins cher, ce qui reste rare, c'est de savoir quoi construire et pour qui. » (post original)

On fait le même constat, à notre échelle.

Les « purs devs » qui produisent du code voient leur terrain de jeu se réduire à mesure que monte la capacité de l'IA à surpasser les humains sur cette partie-là. Les attentes se portent désormais sur tout le reste : la qualité de la spécification en amont, le jugement sur ce qui est pertinent ou pas, et la qualité du process de production en aval.

Ici, le bon développeur augmenté mettra en place les bons pipelines de tests automatisés, supervisera les systèmes de déploiement, et appuiera le PO côté client pour résorber les engorgements de recette que la super-productivité engendre. Paradoxe : plus l'IA écrit vite, plus le reste de l'organisation doit suivre, et plus le dev devient celui qui fluidifie tout ça.

L'IA ne fait pas du développeur un mouton à 5 (ou 6) pattes. Elle révèle qu'il l'avait toujours été, et qu'on avait eu raison de le recruter comme ça.

Ce qu'on retient

Le mouton à 5 pattes n'est plus une blague d'Improba. C'est en train de devenir la norme du secteur, et les organisations qui ont attendu l'IA pour s'y mettre ont dix ans de retard sur les équipes qui, depuis le début, recrutaient des devs capables de parler au client, de jauger un budget, de relire une maquette, de monitorer un déploiement, de penser au SEO.

Si votre équipe technique est encore organisée en silos étanches, avec un dev qui code, un PO qui parle, un UX qui dessine et un devops qui déploie, l'IA ne va pas tuer ces rôles. Elle va tuer la possibilité qu'ils ne se parlent pas.

Si vous vous demandez comment faire évoluer vos équipes dans ce sens, parlons-en. On a quelques années d'avance à partager.