L’intelligence artificielle générative est en train de bouleverser le métier de développeur. Elle complète des lignes de code, corrige des erreurs, produit des tests et peut désormais bâtir une application à partir de quelques instructions formulées en langage courant. Cette facilité nouvelle donne l’impression que les entreprises pourront bientôt développer elles-mêmes leurs logiciels pour une fraction du prix demandé par les éditeurs. Les premiers chiffres invitent pourtant à regarder au-delà de la démonstration technique. Une étude publiée par le National Bureau of Economic Research, portant sur plus de 100 000 développeurs utilisant différentes générations d’outils d’IA, mesure une hausse cumulée de 180 % du nombre de modifications de code. Mais le nombre de projets réellement lancés n’augmente que de 50 % et celui des nouvelles versions mises en production de 30 %. Autrement dit, l’IA accélère spectaculairement l’écriture, beaucoup moins la livraison d’un logiciel utilisable.
Ce décalage rappelle une réalité ancienne de l’économie numérique : le code n’est qu’une partie du coût d’un logiciel. Il faut encore définir le besoin, intégrer l’outil au système d’information, vérifier la qualité des données, tester les fonctionnalités, corriger les failles, documenter le produit, former les utilisateurs et assurer sa maintenance pendant plusieurs années.
C’est précisément le point soulevé par WeeFin, éditeur français spécialisé dans les outils destinés à la finance durable. Selon l’entreprise, l’IA ne fait pas disparaître le traditionnel arbitrage entre développer un logiciel en interne, le « build », et acheter une solution existante, le « buy ». Elle déplace simplement le centre de gravité de la décision.
Le code devient bon marché, pas la responsabilité
L’économiste Ronald Coase expliquait dès les années 1930 que les entreprises choisissent entre produire en interne et acheter sur le marché en fonction des coûts de transaction. L’IA fait chuter l’un de ces coûts : celui de la production initiale du code. Elle ne supprime cependant ni les coûts de coordination ni ceux liés à la durée de vie du produit.
Dans certains cas, elle peut même générer une nouvelle dette technique. Plus une entreprise produit rapidement du code, plus elle doit mobiliser de ressources pour le relire, le tester et le sécuriser. Veracode estime ainsi que seuls 55 % des échantillons de code produits par l’IA passent ses contrôles de sécurité. Cela ne signifie pas que l’IA code systématiquement mal, mais que sa production ne peut pas être considérée comme fiable par défaut. McKinsey observe de son côté que les développeurs peuvent accomplir certaines tâches jusqu’à deux fois plus rapidement grâce à l’IA. Le cabinet souligne toutefois que les entreprises doivent adapter leur organisation, leurs processus de contrôle et la répartition des responsabilités pour transformer ces gains techniques en véritable productivité économique.
Dans la finance, le développeur amateur reste responsable
La question est particulièrement sensible dans la banque, l’assurance et la gestion d’actifs. Une application fabriquée par un analyste financier à l’aide d’un agent conversationnel peut sembler anodine. Dès lors qu’elle traite des données sensibles, produit des indicateurs ou influence une décision d’investissement, elle devient pourtant un véritable outil opérationnel. Depuis janvier 2025, le règlement européen DORA impose aux entreprises financières concernées d’identifier et de maîtriser les systèmes, processus et technologies informatiques soutenant leurs fonctions critiques. La responsabilité ne disparaît donc pas lorsqu’un outil a été conçu en interne plutôt qu’acheté à un prestataire.
Au Royaume-Uni, le cadre PRA SS1/23 va dans le même sens pour les établissements qui entrent dans son champ d’application. Il exige notamment un inventaire des modèles, une gouvernance clairement attribuée, des procédures de validation et un suivi pendant toute leur durée de vie. Le texte couvre les modèles développés en interne comme ceux fournis par des prestataires et invite également les banques à contrôler certaines méthodes quantitatives ou certains algorithmes qui ne seraient pas formellement classés comme des modèles. Il faut cependant éviter de présenter cette règle britannique comme une obligation universelle : elle concerne principalement les banques, sociétés de crédit immobilier et entreprises d’investissement britanniques autorisées à utiliser des modèles internes pour calculer leurs exigences de fonds propres.
Développer ce qui différencie, acheter ce qui se banalise
L’IA ne condamne donc ni le logiciel interne ni les éditeurs. Elle peut rendre le développement maison particulièrement pertinent lorsqu’un outil repose sur des données propriétaires, un savoir-faire spécifique ou une méthode constituant un avantage concurrentiel. À l’inverse, acheter une solution reste souvent plus rationnel pour les fonctions standardisées ou fortement réglementées. Un éditeur peut répartir les coûts de cybersécurité, de conformité et de maintenance entre de nombreux clients. Cette mutualisation constitue une économie d’échelle que quelques lignes de code générées gratuitement ne suffisent pas à reproduire. Le choix d’un fournisseur crée néanmoins d’autres risques : dépendance technologique, hausse des abonnements, difficulté à récupérer ses données ou impossibilité de faire évoluer le produit assez rapidement. La bonne réponse sera donc souvent hybride, avec un socle industriel acheté sur le marché et des briques différenciantes développées en interne.