Construire ou acheter un logiciel interne : trancher étage par étage

L'ancienne question « construire ou acheter » se posait logiciel par logiciel, sur le coût et le délai : construire était lent et cher mais épousait le besoin, acheter était rapide mais vous obligeait à vous plier à l'outil. Elle se posait aussi comme si la réponse valait pour tout le système d'information. Ce n'est pas le cas, et ça ne l'a jamais été.

Si vous ne lisez qu'une chose dans ce guide, lisez celle-ci : l'arbitrage se tranche étage par étage. Ce que l'éditeur porte mieux que vous s'achète. Le logiciel sectoriel dépend de son prix et des règles qu'il tient à votre place. Ce qui vous distingue se construit. Et l'outil qui construit ce dernier étage relève lui-même du premier : il s'achète.

Ce qui a changé : construire est devenu possible, le reste n'a pas bougé

Deux mouvements se produisent en même temps, et ils ne se contredisent pas.

Construire est devenu praticable là où ça ne l'était pas. Dans l'étude de McKinsey publiée en août 2026, 32 % des répondants déclarent que leur organisation a renoncé à acheter au moins un logiciel ou une fonctionnalité, parce qu'elle pouvait la construire en interne avec des outils de code IA (1 719 participants dans 97 pays, terrain de mai à juin 2026).

Et le prix de ce qu'on achète monte. Dans une enquête du Cigref publiée en mai 2026 auprès de 54 directeurs du numérique, le coût des services de cloud et de logiciel a augmenté en moyenne de 8,7 % par an sur trois ans, et 71 % des répondants jugent cette trajectoire difficilement ou non soutenable.

Ni l'un ni l'autre ne dit qu'il faut tout construire. L'IA a fait baisser le coût de la première version d'un logiciel, pas celui de sa vie entière : les règles qui changent, les données qui s'accumulent, les évolutions qui ne doivent rien casser. Ce qui a bougé, c'est l'endroit où construire vaut la peine. Pour le trouver, il faut regarder le système d'information par étages.

Les trois étages, et la règle de chacun

Premier étage : ce que l'éditeur porte mieux que vous

La paie, la comptabilité générale, la messagerie, la gestion de la relation client dans sa forme standard. Ce qui fait la valeur de ces logiciels n'est pas l'écran. C'est ce que l'éditeur porte pour vous : des règles qui changent chaque année, une conformité qui doit tenir dans plusieurs pays, des mises à jour de sécurité, un support. Le reconstruire, c'est reprendre cette charge à votre compte, pour un résultat qui ne vous distingue de personne.

La règle : acheter. Et s'adapter à la façon de faire de l'éditeur, parce que c'est précisément ce que vous payez.

Une nuance compte. Cet étage ne se définit pas par la banalité de la fonction, mais par ce que l'éditeur porte. Un petit utilitaire générique, sans règle ni conformité derrière lui, se construit désormais en quelques heures. Une paie multi-pays ne se construit pas, même avec l'IA, parce que ce qu'elle coûte n'est pas le code.

Deuxième étage : le logiciel sectoriel

Le logiciel conçu pour votre métier : la gestion de la maintenance, la planification de production, la gestion de chantier, le logiciel de votre profession réglementée. Il couvre une partie de votre façon de travailler, pas toute. C'est l'étage où l'arbitrage est réellement ouvert.

La règle : ça dépend de deux choses, pas d'une.

• Le prix, et sa trajectoire. Ce que coûte la licence aujourd'hui, et ce qu'elle coûtera au prochain renouvellement. C'est à cet étage que les hausses unilatérales pèsent le plus, parce que les alternatives sont rares.
• La charge réglementaire que l'éditeur tient à votre place. Si le logiciel porte des règles propres à votre secteur, qui changent et qu'il faudrait suivre vous-même, il vaut plus que son écran. S'il porte surtout votre façon de travailler, et que vous la contournez déjà, il vaut moins que son prix.

Une question tranche souvent : qu'est-ce que vous payez, les règles ou l'écran ?

Troisième étage : ce qui vous distingue

L'outil de chiffrage qui combine vos coûts, vos marges et vos contraintes de capacité. Le suivi qui consolide des informations éparpillées entre plusieurs entités ou plusieurs logiciels. Le portail où vos fournisseurs et vos partenaires déposent leurs informations dans votre format. Ce qui les réunit : la logique est la vôtre, et aucun éditeur ne la porte à votre place. Aujourd'hui, cet étage vit souvent dans un tableur partagé, un fil d'e-mails, une application que plus personne ne maintient, ou un besoin qui attend dans le backlog de l'informatique.

La règle : construire. Aucun logiciel du marché ne fera ce qui vous distingue, par définition, et le plier à un outil générique vous coûte plus que ce qu'il vous fait économiser.

Exemple : une organisation qui range son portefeuille

Prenez une organisation de taille moyenne qui passe en revue ses logiciels, fonction par fonction. C'est une illustration, pas un cas client.

Ressources humaines. La paie est au premier étage : elle s'achète, sans discussion. Le parcours d'intégration d'un nouveau salarié, qui passe par trois entités, quatre validations et un équipement à commander, n'est couvert par aucun logiciel du marché sans contournement. Il est au troisième.

Finance. La comptabilité générale est au premier étage. Le rapprochement entre les commandes, les réceptions et les factures, avec les tolérances que la direction financière a fixées elle-même, vit dans un tableur. Il est au troisième.

Opérations. Le logiciel de gestion de la maintenance est au deuxième étage. Il porte peu de règles réglementaires, sa licence augmente à chaque renouvellement, et les équipes exportent déjà ses données dans un tableur pour faire ce qu'il ne fait pas. Il se réexamine.

Commercial. La gestion de la relation client est au premier étage. Le configurateur de devis, qui applique vos règles de remise et vos combinaisons de produits, est au troisième.

Deux choses ressortent de cette revue. L'arbitrage se fait par morceau, pas par fonction : chaque fonction a un pied au premier étage et un au troisième. Et le troisième étage n'était pas vide, il était dans des tableurs, parce que le construire n'était pas à portée.

Les deux erreurs coûteuses, et elles sont symétriques

Construire à l'étage qui s'achète. C'est l'erreur de ceux qui reconstruisent ce que l'éditeur portait, et reprennent à leur compte une charge qui ne les distingue pas. Beaucoup d'entreprises ont voulu entraîner leur propre modèle de langage. L'entraînement maison est devenu marginal : on achète l'accès à un modèle du marché, et on construit ce qui se trouve au-dessus. Le modèle était au premier étage.

Acheter à l'étage qui se construit. C'est l'erreur inverse, et elle est plus discrète parce qu'elle ressemble à une décision raisonnable. On achète un logiciel du marché pour un processus qui vous est propre, puis on le paramètre, on le surcharge, on fait développer des spécifiques chez l'éditeur, et on finit par exporter ses données dans un tableur pour faire ce qu'il ne fait pas. Vous payez la licence d'un outil que vous avez plié à vos règles, et vous portez quand même la complexité.

Construire ne veut plus dire monter une équipe

Le vrai frein du troisième étage n'a jamais été l'envie. C'était que construire voulait dire recruter une équipe, attendre des mois, et dépendre de la personne qui avait écrit le code. Plusieurs façons de construire existent désormais. Chacune est légitime, et chacune s'arrête à un endroit précis.

Les cinq questions à poser à toute façon de construire

Au troisième étage, la question n'est plus « pouvons-nous nous permettre de le construire ? », mais « si nous le construisons, est-ce que ça durera ? ». Cinq questions y répondent, et elles valent pour un projet interne comme pour n'importe quelle solution.

1. Qui valide ce qui est produit, et peut-il le lire ? Si seul un développeur qui relit du code peut dire que c'est juste, votre capacité à construire est votre capacité de relecture.
2. Que deviennent les données déjà là quand l'application change ? C'est la partie risquée de toute évolution. Une application qui repart de zéro à chaque changement de structure ne dure pas.
3. La construction peut-elle atteindre vos systèmes de production ou vos données réelles ? La bonne réponse est qu'elle ne le peut pas par construction, pas qu'elle en est empêchée par un réglage.
4. Où vit le code quand c'est fini, et de quoi a-t-il besoin pour tourner ? Dans votre dépôt, sur l'infrastructure de votre choix, ou sur la plateforme de quelqu'un d'autre.
5. Qui porte les évolutions dans un an ? Le besoin changera. Si la réponse est « la personne qui l'a construit », le problème n'est que repoussé.

La vitesse de la première version ne figure pas dans la liste. C'est la partie que tout le monde sait déjà faire.

Checklist : où se range votre besoin

Construisez si

• Le processus vous est propre, et il comptera encore dans trois ans.
• Il vit aujourd'hui dans un tableur partagé, un fil d'e-mails, ou une application que plus personne ne maintient.
• Le logiciel du marché que vous avez essayé, il a fallu le plier à vos règles.
• Le besoin va continuer de changer, et d'autres versions suivront la première.
• Quelqu'un, côté métier, porte le besoin et peut dire si le résultat est juste.

Achetez si

• Le processus est le même chez vous que chez vos concurrents.
• L'éditeur porte des règles, une conformité ou des mises à jour que vous devriez sinon suivre vous-même.
• Vous êtes prêt à adopter sa façon de faire, et elle vous convient suffisamment.
• Le prix et sa trajectoire restent raisonnables au regard de ce qu'il porte pour vous.

Questions : les cinq qui reviennent le plus, et leurs réponses courtes

Avec l'IA, ne peut-on pas tout construire ? On peut construire beaucoup plus qu'avant, pas tout. Le premier étage vaut par ce que l'éditeur porte, les règles, la conformité, les mises à jour, et l'IA ne vous en décharge pas. Construire la paie reste une mauvaise idée, même si le code est devenu bon marché.

Et la maintenance ? C'est la vraie question du troisième étage, et c'est pour ça que la vitesse de la première version compte si peu. Le coût d'un logiciel est dans ses évolutions : ce qu'il faut changer sans rien casser, et les données qu'il faut garder quand la structure change.

Faut-il des développeurs pour construire ? Plus nécessairement. Ce qu'il faut, c'est quelqu'un qui porte le besoin et sache dire si le résultat est juste. Si vous avez une équipe technique, elle garde la main là où elle le souhaite. Si vous n'en avez pas, le troisième étage n'a plus à attendre dans le backlog.

Que faire des applications déjà construites à l'IA par les équipes ? C'est le troisième étage qui s'est construit tout seul, sans cadre. Le besoin était réel. Ce qui manque, c'est de savoir ce que ces applications font, où elles tournent, et qui les fera évoluer. Les cinq questions ci-dessus s'appliquent à elles aussi.

Et si notre éditeur sectoriel augmente ses prix ? C'est exactement le moment de réexaminer le deuxième étage. Pas pour tout reconstruire, mais pour séparer ce que l'éditeur porte vraiment pour vous de ce que vous lui payez pour un écran.

Maleus : l'outil qui construit le troisième étage s'achète

Voilà le retournement qui ferme l'arbitrage. Une AI software factory relève elle-même du premier étage : c'est un produit, que vous achetez, parce qu'il porte pour vous ce que vous ne voulez pas porter, le cycle de livraison entier. Ce que vous construisez avec, c'est ce qui vous distingue. Vous achetez la capacité de construire, et vous construisez ce qui est à vous.

Maleus est une AI software factory autonome pour le logiciel interne. Une équipe de spécialistes IA couvre tout le cycle de livraison, un pour chaque rôle : produit, design, analyse, développement, qualité, données et déploiement. La personne qui porte le besoin valide la spécification, écrite en langage courant, avant que quoi que ce soit ne soit construit, puis recette le résultat dans l'application qui tourne.

L'application livrée est entière, backend compris, en code standard dans votre dépôt Git, sur l'infrastructure de votre choix. Chaque construction s'exécute isolée, sans accès permanent à vos systèmes de production, et chaque action est consignée. SOC 2-ready et compatible ISO 27001.