Vous avez demandé un devis pour un outil interne. Vous en avez reçu deux. L'un annonce 4 000 euros en trois semaines, l'autre 18 000 euros en dix semaines. Les deux disent développer un logiciel avec l'IA. Vous cherchez d'où vient l'écart, et personne ne vous l'explique clairement. C'est normal : les deux devis ne parlent pas du même objet. L'un vend l'écriture du code, l'autre vend un outil qui tourne encore dans deux ans avec vos données dedans et vos équipes qui s'en servent tous les matins.
Cet article n'est pas une prospective sur l'avenir du métier. C'est une grille de lecture pour un dirigeant qui doit arbitrer entre deux propositions.
Ce que l'IA change vraiment quand on développe un logiciel avec l'IA
Commençons par l'honnêteté : le changement est réel. Nous utilisons ces outils tous les jours, et nous ne reviendrions pas en arrière. Mais le gain se concentre sur une partie du travail, pas sur l'ensemble.
Ce qu'elle accélère
L'écriture du code, d'abord. Ce qui prenait deux jours de saisie prend souvent quelques heures. Les tâches répétitives, ensuite : produire vingt écrans qui se ressemblent, brancher un export, générer les tests. La documentation, enfin, qui était traditionnellement le premier poste sacrifié dans les projets pressés.
Elle accélère aussi le prototype. Montrer une maquette cliquable en deux jours plutôt qu'en deux semaines, cela change la conversation avec vos équipes. On corrige avant de construire, pas après.
Ce qu'elle n'accélère pas
Comprendre votre métier. Un agent de code ne sait pas que vos commerciaux appellent « dossier » ce que la compta appelle « affaire », ni pourquoi le tarif change quand le client est un ancien salarié. Cette information n'est écrite nulle part. Elle sort d'entretiens.
Décider ce qu'on ne fait pas. C'est le vrai travail de conception. Sur une demande initiale, la moitié des fonctions demandées ne servent à personne au bout de six mois. Arbitrer, c'est un choix économique, pas une tâche technique. Aucun agent ne le fera à votre place, parce qu'il ne connaît ni votre trésorerie ni vos priorités de l'année.
Reprendre l'existant. Vos données vivent dans des fichiers Excel avec trois colonnes en doublon, des dates au format libre et des noms de clients écrits de quatre façons. Le nettoyage et la reprise sont souvent le poste le plus lourd d'un projet. L'IA aide à écrire les scripts. Elle ne décide pas quelle version du client « Dupont / DUPONT SA / Dupond » est la bonne.
Faire adopter l'outil. Une application que personne n'ouvre coûte exactement son prix, moins zéro bénéfice. La formation, l'accompagnement des trois semaines qui suivent la mise en service, la reprise des habitudes : c'est du temps humain, et il ne baisse pas.
En répondre dans deux ans. Quand un bug bloque une facturation un vendredi soir, il faut quelqu'un qui comprenne le code, pas quelqu'un qui redemande à une machine de le régénérer.
Les chiffres qui circulent, et ce qu'ils mesurent
Deux chiffres reviennent partout en ce moment. Ils méritent d'être posés côte à côte.
| Ce qu'on lit | La source | Ce que ça mesure réellement |
|---|---|---|
| L'IA réduit les coûts de développement de 10 à 25 % | GoodFirms, enquête 2026 | L'ensemble d'un projet, cadrage et recette compris |
| Dans 45 % des cas, un modèle qui a le choix entre une méthode sûre et une méthode qui ne l'est pas choisit la seconde | Veracode, GenAI Code Security Report 2025, 80 tâches sur plus de 100 modèles | Le code brut d'un modèle, avant toute relecture humaine. Pas le code d'un projet livré |
| « Un logiciel à 50 000 euros en 2023 en coûte 5 000 aujourd'hui » | Argument commercial entendu sur le marché | Rien de vérifiable, et probablement pas le même périmètre |
Retenez le premier. Dix à vingt-cinq pour cent, c'est significatif. Sur un projet à 20 000 euros, cela fait 2 000 à 5 000 euros d'économie réelle. Ce n'est pas une division par dix.
Quand quelqu'un vous annonce une division par dix, deux explications sont possibles. Soit le projet de référence à 50 000 euros était mal vendu au départ. Soit le nouveau projet à 5 000 euros ne contient ni cadrage, ni reprise de données, ni recette, ni suivi. C'est un prototype livré comme un produit fini. Ça marche parfois. Ça se voit surtout au bout de quatre mois, quand le premier cas particulier casse tout.
Le second chiffre, celui de Veracode, ne doit pas vous faire peur du code généré. Il doit vous faire poser une question précise à votre prestataire : qui relit, et selon quelle méthode. Un devis qui ne comporte aucune ligne de revue de code vous vend le brouillon d'un agent.
Où passent les semaines d'un projet, et lesquelles l'IA raccourcit
Voici comment se répartit le travail sur un outil métier de taille moyenne, du type gestion d'interventions ou suivi d'affaires pour une entreprise de trente personnes.
| Étape | Poids historique | Effet des outils IA |
|---|---|---|
| Entretiens métier, cadrage, arbitrages | 15 à 20 % | Quasi nul |
| Conception des écrans et des parcours | 10 à 15 % | Fort sur les maquettes, faible sur les choix |
| Construction | 35 à 45 % | Très fort |
| Reprise et nettoyage des données existantes | 10 à 20 % | Moyen |
| Recette, corrections, cas particuliers | 10 à 15 % | Faible à moyen |
| Formation et accompagnement au démarrage | 5 à 10 % | Nul |
Le poste qui pèse le plus lourd est aussi celui que l'IA transforme le plus. C'est pour cela que les délais bougent réellement. Mais comme ce poste ne représente pas la totalité du projet, le délai global ne s'effondre pas : il se comprime.
Un exemple, sur un projet que nous livrons à la mi-septembre : MyPosture, une plateforme de formation reprise entièrement. Trois interfaces distinctes (les apprenants, les coachs, une administration complète), des parcours et des supports de présentation éditables de bout en bout, au point que les administrateurs ont aujourd'hui la main sur la quasi-totalité des textes et des illustrations. Une application existait déjà, construite par d'autres. Nous avons tout repris de zéro, et cette application nous a servi de prototype : savoir précisément ce que l'outil devait faire a supprimé des semaines d'incertitude.
Le résultat : deux mois de construction. Refait proprement depuis le début avec les méthodes de 2023, le même projet nous aurait demandé sept à huit mois.
Ce temps gagné n'est pas parti en marge. Il est allé dans les deux postes que le tableau ci-dessus donne pour incompressibles.
D'abord le cadrage. Nos clients ne sont pas développeurs, et nous ne leur demandons pas de l'être. Ils imaginent quelque chose, et ce n'est qu'en voyant l'outil qu'ils découvrent l'idée qui manquait, ou qu'ils nous apprennent qu'un chiffre annoncé comme fixe dépend en réalité de trois paramètres. Cette information n'existe pas au moment du devis. Elle sort de l'usage.
Ensuite la façon de livrer. Puisque construire coûte moins cher, nous livrons pendant la construction et non à la fin. Le client reçoit des maquettes qu'il manipule vraiment, et un module de commentaires posés à même l'écran, comme sur une maquette partagée, pour nous dire ce qui cloche là où ça cloche. Nous ne corrigeons plus un logiciel livré : nous corrigeons un prototype pendant qu'il est encore souple.
« L'IA écrit le code, alors pourquoi payer 15 000 euros ? »
C'est la question que tout le monde pose maintenant, et elle est légitime. Voici la réponse en trois temps.
Vous ne payez pas des lignes de code. Vous payez le fait que quelqu'un ait passé six heures avec votre responsable d'atelier à comprendre pourquoi une commande peut être « en attente » pour quatre raisons différentes, et que ces quatre raisons se retrouvent dans l'outil. C'est ce travail qui fait qu'un logiciel est utilisé ou abandonné.
Vous payez une décision de périmètre. Sur une liste de trente fonctions demandées, un bon constructeur en enlève douze. Pas par paresse : parce qu'elles complexifient l'outil pour un usage marginal. Cette suppression vous fait économiser plus que n'importe quel gain de productivité sur le code. Ce qui ne se délègue jamais à un agent, c'est le choix de ce qu'on tue en premier.
Vous payez une responsabilité dans le temps. Un logiciel métier vit trois à sept ans. Il évolue, il se branche à d'autres outils, il subit un changement de réglementation. Le coût total ne se joue pas à la livraison, il se joue sur la durée. C'est le même raisonnement que pour n'importe quel achat logiciel, et nous l'avons détaillé dans notre article sur le prix d'un développement logiciel sur mesure.
Le prototype et le « vibe coding » : utiles, mais ce n'est pas un logiciel
Une pratique s'est répandue : décrire ce qu'on veut en langage courant, laisser un outil produire l'application, ajuster à vue. On appelle cela le vibe coding. Pour un dirigeant, c'est tentant, et pour certains usages c'est le bon choix.
Quand c'est pertinent :
- Tester une idée avant d'engager un budget.
- Un outil utilisé par deux ou trois personnes, sans données sensibles.
- Remplacer un fichier de calcul devenu ingérable, sans enjeu de continuité.
- Montrer à vos équipes à quoi ressemblerait la solution avant de la commander.
Quand ça devient risqué :
- Dès que l'outil porte des données clients ou des données de paie.
- Dès que plusieurs personnes y écrivent en même temps.
- Dès qu'un arrêt d'une journée coûte de l'argent.
- Dès que vous devrez le faire évoluer sans la personne qui l'a produit.
Le problème n'est pas la qualité initiale. Le problème, c'est la dette technique invisible : un ensemble qui fonctionne le premier jour, que personne ne comprend le centième, et qu'il faut refaire au lieu de le modifier. Le coût de la refonte annule largement l'économie de départ.
Les quatre questions à poser à un prestataire qui code avec l'IA
Vous n'avez pas besoin d'être technique pour trier deux devis. Posez ces quatre questions.
1. Qui relit le code, et à quel moment ? La bonne réponse mentionne une relecture humaine systématique, pas un contrôle final. Si personne n'est nommé, passez votre chemin.
2. À qui appartient le code ? La propriété du code doit être écrite noir sur blanc, avec la remise des sources. Sans cela, votre outil est un logiciel loué qui ne dit pas son nom. Vous ne pourrez pas changer de prestataire.
3. Que se passe-t-il au troisième mois ? Demandez ce que couvre le suivi, à quel rythme, et ce qui est facturé en plus. Un projet livré et abandonné coûte plus cher qu'un projet suivi.
4. Qu'est-ce que vous ne construisez pas ? Un prestataire qui accepte tout ce que vous demandez ne vous conseille pas. Il exécute. Sur un outil métier, c'est la meilleure façon de livrer une usine à gaz.
Comment nous travaillons, concrètement
Il serait malhonnête de vous donner une grille de lecture sans nous y soumettre. Voici donc notre façon de faire, et ce qu'elle automatise vraiment.
Ce qui est automatisé chez nous, c'est la production du code. Le reste ne l'est pas, et c'est un choix de méthode, pas une réserve de principe.
Nous avançons module par module, et chaque module passe par la même chaîne. On écrit d'abord les spécifications : ce que le module doit faire, et pour qui. Un humain les relit. On en tire ensuite les parcours utilisateur, ce que chaque personne fait concrètement, écran par écran. Un humain les relit aussi. Le plan de tests, lui, est produit par la machine : c'est du travail mécanique et exhaustif, exactement ce qu'elle fait mieux que nous. Vient la construction. Puis une vérification humaine à l'écran, qui répond à une seule question : est-ce que ce qui tourne correspond à ce que la personne qui a conçu le module avait en tête ?
Deux relectures humaines avant la première ligne de code, une vérification humaine après, et des tests au fil de l'eau plutôt qu'en bloc à la fin. La règle qui tient tout l'édifice tient en une phrase : nous ne déléguons jamais une application de bout en bout sans intervenir. Un projet mené comme ça ne révèle son problème que le dernier jour, et il faut alors défaire la moitié du travail. Nous préférons le trouver le mardi de la deuxième semaine.
Le reste est du travail d'atelier. Le cadrage se fait en présentiel ou en visio, jamais par formulaire. Nous y voyons deux populations qu'on confond souvent : ceux qui commandent le logiciel, et ceux qui vont s'en servir tous les matins. Ce sont rarement les mêmes personnes, et c'est la seconde qui détient les règles que personne n'a jamais écrites. Puis des points réguliers, et une obsession : donner la main à vos administrateurs sur tout ce qu'il est raisonnable de rendre éditable. Un client obligé de nous appeler pour changer un libellé est un client que nous avons mal servi.
Ce que ça change concrètement pour une PME de 10 à 80 salariés
La bonne nouvelle est réelle : des projets qui n'étaient pas finançables il y a trois ans le sont aujourd'hui. Un outil de suivi de production propre à votre atelier, un portail pour vos sous-traitants, un module de devis qui suit vraiment votre grille tarifaire. Ce type de besoin ne justifiait pas 40 000 euros. Il peut se traiter aujourd'hui dans une fourchette bien plus accessible.
La mauvaise nouvelle est tout aussi réelle : la baisse du coût de production attire des offres qui vendent la partie facile en oubliant le reste. Le cahier des charges n'a jamais été aussi important, non pas comme document de cent pages, mais comme accord clair sur ce que l'outil fait, ce qu'il ne fait pas, et qui s'en sert.
Si vous hésitez encore sur la nature même du besoin, deux lectures complémentaires : ce qu'est un logiciel métier sur mesure et à quoi sert un logiciel de gestion.
Ce qu'on écrit avant d'écrire une ligne de code
Puisque tout cet article tient sur l'idée que la partie non automatisable décide du résultat, autant montrer à quoi elle ressemble.
Le premier livrable d'un projet s'appelle chez nous un cahier de cadrage. Pas un cahier des charges : ce document-là est dense, spécifique et technique, et un dirigeant ne le lit pas vraiment. Le nôtre est écrit pour être lu par quelqu'un dont ce n'est pas le métier. Il énumère le besoin, l'objectif de l'outil, les fonctionnalités, ce que chacune fait, et à qui elle s'adresse.
Les cas particuliers et les règles métier n'y figurent pas encore. Ils sortent à l'étape suivante, le prototypage, quand vous manipulez des maquettes interactives et nous faites vos retours au fil de l'usage. C'est là qu'on apprend qu'une commande peut être « en attente » pour quatre raisons différentes.
Ce cahier est facturé, et il est à vous. Facturé parce que c'est du temps passé, et parce qu'il constitue une ébauche de cahier des charges assez sérieuse pour que vous puissiez vous arrêter là, aller demander deux autres devis, et les comparer enfin sur une base identique. Nous préférons cela à un cadrage offert qui vous lie.
De notre côté, il n'a rien d'un document de forme : il fixe l'architecture et le découpage en modules, et c'est de lui que découle toute la construction. C'est aussi le passage le plus difficile du métier, celui où l'on traduit une réalité commerciale en quelque chose qui puisse être bâti.
En résumé
L'IA a changé une chose importante : la construction coûte moins cher et va plus vite. Elle n'a rien changé à ce qui fait qu'un logiciel interne réussit ou échoue, c'est-à-dire la compréhension du métier, les arbitrages de périmètre, la qualité de la reprise des données et l'adoption par les équipes.
Un devis très bas ne ment pas forcément. Il décrit simplement un périmètre plus court. Votre travail de dirigeant est de vérifier ce qui manque, pas de comparer deux totaux.
Faire le tri sur votre cas
Vous n'avez pas besoin d'un cahier des charges pour savoir si un outil sur mesure se justifie chez vous, ni pour lire correctement deux devis qui varient du simple au décuple. Trois questions suffisent : quel fichier bloque aujourd'hui, combien d'heures par semaine il coûte, et ce qui se passe quand la personne qui le tient est absente.
Le diagnostic Magram répond à ces trois questions en une dizaine de minutes. Vous repartez avec un ordre de grandeur chiffré et un avis franc, y compris quand la réponse est « un logiciel du marché suffira ».