ESN Rouen : pourquoi nous avons changé de modèle

Ce que le modèle classique de l’ESN coûte à une DSI

Le modèle dominant de l’ESN repose sur la régie : vous achetez des jours-homme à un TJM, pas un résultat. Le prestataire s’engage sur la présence d’un profil, rarement sur ce qu’il produit. Ce déplacement du risque vers le client n’est pas une question de bonne volonté : il est structurel.

S’ajoute le cycle de staffing. Entre l’expression du besoin, la recherche du profil, les entretiens et la disponibilité réelle, il s’écoule des semaines — souvent des mois. Et le profil retenu est pensé comme interchangeable, parce que c’est la condition d’un modèle qui vend de la compétence au volume.

Reste le turnover. Quand un consultant part, la connaissance de votre SI part avec lui. La DSI paie alors deux fois : la montée en compétence du remplaçant, et les régressions qu’un contexte perdu finit par produire.

Pourquoi nous avons construit une autre ESN à Rouen

Popixa part d’un constat simple : l’IA a changé l’économie du développement, pas les besoins d’une DSI. Le code répétitif — squelettes, tests, migrations mécaniques — ne justifie plus de facturer des jours au volume. Ce qui garde de la valeur, c’est la conception, l’arbitrage, la compréhension du métier.

Nous avons donc inversé le modèle : de petits binômes d’ingénieurs-consultants qui conçoivent et développent, l’IA en renfort sur la partie répétitive. Pas d’agents autonomes lâchés sur votre code : des ingénieurs outillés, responsables de chaque ligne. Notre ancrage est rouennais, notre terrain est la Normandie et au-delà — le propos, lui, vaut partout.

L’IA écrit vite. Nos ingénieurs conçoivent.

Soyons précis sur ce que l’IA fait bien, et sur ce qu’elle ne fait pas. Elle écrit vite, elle ne se lasse pas du répétitif, et elle se trompe avec assurance. Elle ne connaît pas votre métier, ne mesure pas les conséquences d’un choix d’architecture, et ne décide de rien.

C’est précisément pour cela que le duo fonctionne. L’ingénieur cadre le problème, conçoit la solution, délègue le mécanique, puis relit et corrige. Si vous êtes sceptique face aux promesses de l’IA, tant mieux : ce scepticisme est le nôtre, et c’est lui qui structure notre méthode.

Ce que nous déléguons à l’IA est cadré : le squelette d’un module, une batterie de tests, une conversion mécanique. Ce que nous ne lui déléguons jamais : un choix d’architecture, un arbitrage de sécurité, une décision qui engage votre SI. La frontière est simple — l’IA produit, l’ingénieur décide.

Une ESN à Rouen qui livre, au lieu de vendre des jours

Concrètement, l’engagement porte sur ce qui est livré : un périmètre, des critères d’acceptation, un binôme qui reste. Pas une file de profils qui se succèdent sur votre projet, ni un compteur de jours qui tourne. Le binôme qui conçoit est celui qui livre — et celui qui répond ensuite.

Cette responsabilité se mesure aussi dans la relation courante : un incident bloquant est pris en charge sous 4 h ouvrées, et toute sollicitation reçoit une réponse sous 24 h ouvrées. Ce sont des engagements publics, pas des intentions. Ils tiennent parce que l’équipe est petite et que votre contexte ne se dilue pas entre des interlocuteurs qui changent.

La confiance ne se déclare pas : elle s’audite

Il reste la question que tout DSI doit poser : qui répond du code produit avec l’IA ? Notre réponse est vérifiable : 100 % du code est relu par un ingénieur, et chaque relecture porte un nom. Pas « l’équipe », pas « le process » : un ingénieur nommé, engagé sur ce qu’il a validé.

Tout est tracé dans votre Git, pas dans le nôtre. Chaque commit, chaque merge request, chaque relecture reste chez vous, auditable pendant la mission et après. C’est le sens de notre manifeste : la confiance ne se déclare pas, elle s’audite.

Nous documentons aussi ce qui casse : le journal publie nos retours de terrain sur le duo IA + ingénieur — ce qui marche, ce qui échoue, ce que nous corrigeons. Et si vous préférez juger sur pièces, demandez une démo : nous montrons le flux de travail réel, relectures comprises.