L’IA est en train de changer l’économie du développement logiciel

On résume souvent l’impact de l’IA sur le développement à une question de productivité : combien de temps un développeur gagne-t-il avec Cursor, Claude ou un autre assistant ? La question est légitime, mais elle me semble trop petite.

Oui, certaines tâches sont devenues beaucoup plus rapides. Générer une première version d’une fonction, corriger un bug, écrire des tests, produire de la documentation, préparer une requête ou explorer une architecture peut prendre beaucoup moins de temps qu’avant. Mais le vrai changement se situe plus bas dans la chaîne : le coût de production du logiciel diminue.

Et lorsque ce coût diminue, la frontière de ce qu’il est raisonnable de développer se déplace

C’est un point essentiel, parce qu’il existe dans les entreprises une quantité énorme de besoins qui ne justifiaient pas, jusqu’ici, un vrai projet logiciel. Ils étaient trop petits pour un éditeur, trop spécifiques pour un SaaS standard, ou trop modestes pour supporter le coût d’un développement sur mesure classique.

Alors on bricolait. Et souvent, ce bricolage fonctionnait très bien pendant un certain temps.

Je parle souvent d’Excel parce que c’est probablement le meilleur exemple. Excel est un formidable outil. Pour calculer, analyser, simuler, préparer un budget, manipuler rapidement des données ou faire de la finance, il est difficile de faire plus efficace.

Le problème commence lorsqu’il arrête de faire des tableaux et se met à faire tourner un processus.

Un fichier devient le point central d’une validation. On relance par e-mail. On copie une information dans un autre outil. Plusieurs versions circulent. Les priorités sont gérées à la main. Le reporting nécessite de vérifier et consolider des données. Une personne finit par connaître toutes les subtilités du fichier et devient indispensable à son fonctionnement.

À ce stade, Excel n’est plus seulement un tableur. Il est devenu, de fait, une application métier. Simplement sans les droits, l’historique, les contrôles, les notifications, les garde-fous et la traçabilité que l’on attendrait normalement d’une application.

Cela ne veut pas dire qu’il faut sortir tous les fichiers Excel de l’entreprise. Ce serait absurde. La vraie question est de savoir à quel moment l’usage a dépassé l’outil.

Pendant longtemps, même lorsque la réponse était évidente, le passage à une vraie application restait difficile à justifier. Le problème existait, mais le projet informatique semblait disproportionné. C’est précisément ce rapport qui est en train de changer.

Un exemple récent résume bien le sujet. J’ai été contacté par un responsable de la distribution qui cherchait à automatiser la collecte de documents lors des embauches dans ses hypermarchés.

Le besoin était presque banal : un formulaire pour collecter les pièces, un suivi des documents manquants et des relances automatiques. En clair, éviter qu’une personne passe son temps à se mettre des rappels pour penser à envoyer des e-mails.

Il avait déjà regardé plusieurs solutions du marché. Certaines ne souhaitaient tout simplement pas traiter son cas en dessous d’environ 300 onboardings par an. Je comprends très bien la logique d’un éditeur SaaS : il faut standardiser, servir un marché large et atteindre un certain volume. Mais cela crée un angle mort.

Le besoin est trop petit pour l’éditeur, mais suffisamment important pour faire perdre du temps chaque semaine à l’entreprise. Il n’est pas stratégique au point de lancer un programme de transformation sur douze mois, mais il est assez pénible pour mériter une vraie solution.

C’est exactement le type de projet que la baisse du coût de développement rend à nouveau intéressant. Pas la transformation digitale du siècle. Juste un outil simple qui supprime une tâche répétitive, fiabilise un processus et rend le quotidien meilleur.

Il y en a des milliers : un extranet, un portail client, un outil de suivi, un circuit de validation, une collecte documentaire, un tableau de bord, un module qui se connecte à l’ERP, la transformation d’un fichier Excel critique en application collaborative. Des besoins que l’on acceptait autrefois de gérer manuellement parce que développer la bonne solution coûtait trop cher.

Il y a un deuxième effet de l’IA dont on parle moins, et que je trouve presque aussi important que la vitesse de développement : elle change la manière de cadrer un projet.

Le sur-mesure a toujours eu un défaut commercial assez évident. Au départ, le client achète quelque chose qui n’existe pas encore. Il doit imaginer le résultat, comprendre des fonctionnalités encore théoriques, croire à un planning et accepter un budget alors que beaucoup de détails n’ont pas encore été décidés.

Sur de gros projets, on sait traiter cette incertitude. On organise des ateliers, on rédige des spécifications fonctionnelles, on produit des maquettes, on décrit les parcours et les règles métier. Cela prend du temps, mais le budget du projet permet de l’absorber.

Sur un petit logiciel métier, la situation était plus compliquée. Le coût du cadrage pouvait représenter une part importante du projet. Et personne n’a très envie de payer cher uniquement pour obtenir un document qui lui explique ce qu’il pourra peut-être acheter ensuite.

L’IA change cette étape. Après un audit ou quelques échanges sérieux, il devient possible de produire beaucoup plus vite une première version des fonctionnalités, des écrans, des parcours, des règles métier, des spécifications et parfois même des maquettes.

Le client peut donc visualiser beaucoup plus tôt ce qu’il achète. Le projet devient concret avant même d’avoir réellement commencé.

Du sur-mesure, mais avec une expérience d’achat qui se rapproche de plus en plus de celle d’un produit déjà défini.

Cela ne retire pas l’incertitude propre à tout projet logiciel. Il y aura toujours des arbitrages, des détails qui apparaissent en cours de route et des choix techniques à prendre. Mais la peur du vide diminue fortement.

On peut dire plus tôt : voilà les principaux écrans, voilà le parcours, voilà ce qui sera automatisé, voilà les fonctions importantes, voilà le budget et voilà le planning. Pour un dirigeant ou un responsable métier, cela change beaucoup la perception du risque.

Tout cela peut donner l’impression que développer vite suffit désormais. Ce n’est évidemment pas le cas. La vitesse est utile uniquement si elle s’appuie sur un bon cadrage, une architecture correcte et une organisation rigoureuse.  L’IA accélère certaines étapes de la mécanique du développement,  elle ne la remplace pas.

C’est un point important à garder en tête, surtout au moment où le développement assisté par IA devient spectaculaire. Le code est plus facile à produire, mais produire du code n’a jamais été la seule difficulté d’un projet logiciel. Comprendre le besoin, choisir la bonne solution, gérer les exceptions, penser l’expérience utilisateur et prendre les bons arbitrages restent déterminants.

C’est finalement là que je me sépare un peu du discours selon lequel l’IA annoncerait la fin du développement logiciel.

Si produire du logiciel devient plus rapide, si le cadrage devient moins coûteux, si le code peut être généré et testé plus efficacement, alors le nombre de logiciels que nous pouvons raisonnablement construire va augmenter, pas diminuer.

Nous allons probablement voir apparaître davantage de petits logiciels, plus spécifiques, plus proches des métiers et parfois destinés à quelques dizaines de personnes seulement. Des outils qui auraient semblé absurdes à développer il y a cinq ans parce que le coût du projet aurait dépassé la valeur créée.

Le code revient donc au centre, mais d’une manière différente. Une part croissante sera générée, modifiée, testée ou documentée par des machines. La valeur humaine se déplace vers ce qui reste difficile : comprendre le métier, détecter le vrai problème, savoir ce qu’il ne faut pas construire, choisir une architecture, arbitrer et vérifier que l’outil produit réellement un résultat utile.

À mes yeux, c’est l’un des changements les plus intéressants de la période actuelle. L’IA ne rend pas seulement les développeurs plus rapides. Elle redessine l’économie du logiciel et du sur mesure.

Et pour toutes les entreprises dont certains processus critiques vivent encore entre Excel, les e-mails, les copier-coller et la mémoire de quelques personnes, cela ouvre un terrain énorme.

En une phrase

L’IA ne supprime pas le besoin de logiciel : elle rend possible une nouvelle génération d’outils métier jusqu’ici trop petits, trop spécifiques ou trop coûteux à développer. Mais produire plus vite ne dispense pas de produire bien. Nous verrons probablement apparaître beaucoup plus de logiciels dans les prochaines années, et inévitablement beaucoup de mauvais. L’enjeu ne sera donc pas seulement d’aller vite grâce à l’IA, mais de conserver le niveau d’exigence nécessaire pour construire des outils réellement fiables et utiles.