Diasoft explique pourquoi les juniors, la magie de l'IA et une plateforme maison ne sauvent pas les projets de développement

Diasoft et d'autres sociétés informatiques ont passé au crible trois mythes tenaces qui poussent de grands clients à continuer de perdre argent et temps dans le développement. Il s'agit de la conviction qu'un projet complexe peut être accéléré par des embauches massives, qu'un ancien système peut être réécrit presque entièrement par l'IA et que le problème d'efficacité se règle définitivement en lançant une plateforme maison. Les auteurs de la discussion affirment que ces trois idées ne paraissent logiques que sur le papier : dans les vrais projets enterprise, elles ajoutent le plus souvent du chaos, alourdissent la dette technique et renchérissent le coût des changements.

Le premier mythe : « ajoutons du monde et nous irons plus vite ». Les participants rappellent que cette approche contredit la loi de Brooks : plus on jette de personnes dans un projet complexe déjà en retard, plus les coûts de communication grimpent et plus la synchronisation devient difficile. En pratique, cela se traduit par une série de symptômes connus : les équipes produisent des morceaux de système incompatibles, des bugs surgissent aux intégrations, l'UX diverge d'un produit à l'autre et les exigences de scalabilité et de sécurité cessent d'être appliquées de façon uniforme.

C'est particulièrement visible quand des centaines d'équipes travaillent en même temps. Selon les interlocuteurs, les juniors et les développeurs simplement bon marché ne compensent pas le manque de réflexion architecturale. Au contraire, au bout de six à douze mois, l'organisation se retrouve souvent avec une dette technique accumulée et doit refaire une part importante de la solution.

Le deuxième mythe concerne l'IA générative. Ici, la position des experts est plus nuancée : ils ne contestent pas que des outils comme Cursor, des modèles internes et des scénarios agentiques accélèrent déjà le time-to-market, réduisent la routine manuelle et aident à corriger les bugs plus vite. Certaines équipes font même de la consommation de tokens une métrique d'efficacité à part.

Mais il n'en découle pas qu'un réseau de neurones puisse réécrire « en une nuit » un système legacy développé pendant dix ou quinze ans. Quand on parle de centaines de milliers ou de millions de lignes de code, la génération ne suffit pas : la validation, les contraintes d'architecture, les exigences de sécurité de l'information et des standards uniques pour tout le périmètre sont critiques. L'IA fonctionne donc comme une couche utile au sein du pipeline, et non comme un remplaçant autonome de la fonction d'ingénierie.

Pour la migration et la transpilation de masse, il faut toujours des outils déterministes, du parsing, des transformations d'AST et des personnes qui comprennent le contexte métier et peuvent vérifier ce que le modèle a exactement généré.

Le troisième mythe : « construisons notre plateforme et cessons de dépendre du marché ». La discussion note que cette voie fonctionne parfois réellement, mais seulement pour des entreprises à l'horizon d'investissement très long, au budget immense et dont l'activité dépend de façon critique de leur propre plateforme numérique. En guise de repère, on cite le cas d'une grande banque qui a consacré des années et des dizaines de milliards de roubles à une plateforme interne, en relançant le projet plusieurs fois.

Pour la plupart des entreprises, cette stratégie ne signifie pas accélération, mais des années passées à construire de l'infrastructure au lieu de résoudre des problèmes applicatifs. Il existe aussi un contre-argument : en réunissant un petit groupe de spécialistes seniors solides, en leur donnant des pouvoirs et des outils d'IA modernes, on peut parcourir une partie du chemin nettement plus vite qu'avant. Mais même les partisans de cette idée ne proposent pas de fausse dichotomie.

Il s'agit plutôt d'un modèle hybride, où le cœur du produit reste en interne, tandis que des équipes externes ou des éditeurs de plateformes couvrent des services précis et les pics de projet.

De là découle une vision plus pragmatique du marché du développement sur mesure. Les clients achètent de moins en moins de simples heures de programmeurs et attendent de plus en plus que le prestataire prenne en charge le résultat dans son ensemble : monter vite une architecture fonctionnelle, intégrer des contrôles de qualité et de sécurité, appliquer l'IA à bon escient et réduire la taille de l'équipe sans perte de qualité. D'après l'estimation des participants, avec un haut degré d'automatisation et un processus bien construit, une équipe de quatre à cinq personnes peut livrer le volume qui en exigeait auparavant douze à quinze.

Mais cette économie ne surgit pas de nulle part, ni de la « magie des prompts ». Elle est produite par les standards, le pipeline, l'analyse statique, les tests automatiques, des leads expérimentés et une séparation nette entre ce qu'on peut confier à la machine et ce qui reste du ressort de l'humain.

Ce que cela signifie pour le marché : l'ère des réponses simples dans le développement enterprise touche à sa fin. L'embauche massive sans architecture solide ne ressemble plus à un accélérateur efficace, l'IA sans garde-fous ne devient pas une usine à code autonome, et une plateforme maison sans l'échelle d'un grand business devient facilement une distraction coûteuse. Les gagnants seront les équipes capables de combiner expertise senior, approche plateforme et automatisation de la livraison. Dans ce schéma, l'IA n'est pas une baguette magique, mais un amplificateur d'un système d'ingénierie déjà mature.