Bâtir ou acheter
Qui pourra changer une règle de prix dans trois ans ?
Dans les deux scénarios, les règles de votre métier finissent enfermées quelque part où personne chez vous ne peut y toucher. Dans le moteur d'un éditeur, ou dans le code d'un développeur qui est parti.
Faites chiffrer un de vos devisCe qui échoue quand on achète
Ce qui échoue quand on achète
Le moteur de règles ne modélise pas votre métier. C'est la plainte la plus constante des utilisateurs de configurateurs génériques, chez les grands éditeurs comme chez les autres. Votre règle de majoration selon l'épaisseur et la longueur de pliage n'entre pas dans le cadre prévu. On la contourne avec un champ libre, et la règle retourne dans Excel.
L'intégration à l'ERP est traitée trop tard. C'est la cause d'échec la mieux documentée. Elle est repoussée à la fin parce qu'elle est ingrate, et elle fait dérailler le calendrier au moment où le budget est déjà brûlé.
Le vendeur retourne dans Excel. Si l'outil est plus lent que ce qu'il remplace, il perd. Toujours. Aucune directive de direction ne survit à trois semaines de trimestre serré.
La facture de licence n'est pas la facture. Le coût d'implantation représente couramment deux à trois fois la licence annuelle.
Ordre de grandeur avancé par des intégrateurs, qui ont intérêt à le dire. À vérifier auprès de deux fournisseurs plutôt qu'à croire sur parole.
Et le produit peut cesser d'évoluer sous vous. Salesforce CPQ est en fin de vente depuis mars 2025 : les clients existants gardent leur support et leurs correctifs critiques, et Salesforce n'a annoncé aucune date de fin de vie ni forcé aucune migration. Mais l'innovation est ailleurs, et un jour la migration se décide toute seule. Ça arrive aux plus gros aussi.
Ce qui échoue à l'interne
Ce qui échoue quand on bâtit à l'interne
Depuis deux ans, l'argument a changé. Ce n'est plus « on a un développeur », c'est « on va se le faire nous-mêmes avec l'IA ».
Et c'est vrai : vous pouvez sortir un prototype convaincant en quelques jours. La démonstration impressionne. Le problème n'apparaît pas là.
Il apparaît au troisième mois. Quand il faut modifier une règle écrite deux mois plus tôt, dans un code que personne n'a relu. Ce n'est pas une impression : trois équipes de recherche l'ont mesuré chacune de son côté, en quatre relevés publiés, et aucun ne va dans l'autre sens.
Et il apparaît le jour du départ. Celui qui a bâti la chose change d'emploi. Les règles sont dans sa tête et dans son code. Vous venez de remplacer une dépendance à Excel par une dépendance à une personne, avec une couche de complexité en plus.
Ce n'est pas un argument contre l'IA. On construit avec, tous les jours. C'est un argument contre l'IA sans usine autour.
Ce que les autres ont mesuré
Quatre mesures publiées, et elles pointent toutes dans le même sens
45 %
du code généré contient une faille du top 10 de l'OWASP
Veracode · juillet 2025
×8
de blocs de code dupliqués en un an, cinq lignes ou plus
GitClear · 2024
+322 %
de chemins d'escalade de privilèges sur des dépôts d'entreprise
Apiiro · déc. 2024 – juin 2025
+153 %
de défauts de conception sur les mêmes dépôts
Apiiro · déc. 2024 – juin 2025
Chiffres arrêtés au 2 septembre 2026.
La troisième voie
Trois conditions, et elles ne sont pas négociables
01
Les règles vivent hors du code.
Vos grilles de prix, vos compatibilités, vos seuils d'approbation sont des données modifiables dans un éditeur, pas des lignes de programme. Votre analyste change une majoration de matière sans appeler personne.
02
Le dépôt et les données sont à vous.
Aucune licence propriétaire dans la pile. Le jour où vous partez, on vous remet le code et une copie complète de votre base. C'est réglé.
03
La maintenance est un contrat, pas un espoir.
Écrite, avec un périmètre, un délai de réponse et un prix. Pas « on sera là ».
Quelqu'un le bâtit pour vous, sur un socle déjà éprouvé chez d'autres, avec trois conditions non négociables.
Les trois options, côte à côte
Le tableau honnête
| Acheter du marché | Bâtir à l'interne | Faire bâtir sur un socle | |
|---|---|---|---|
| Mise en route | Rapide si votre métier entre dans le cadre. Long s'il n'y entre pas. | Prototype très rapide. Production, beaucoup moins. | Entre les deux. Le socle est fait, votre métier ne l'est pas. |
| Qui change une règle de prix | Un administrateur formé, dans les limites du moteur. | Le développeur qui l'a écrite. Personne d'autre. | Votre analyste, dans un éditeur de règles. |
| Si l'éditeur abandonne le produit | Réimplantation. Ça s'est vu chez les plus gros. | Sans objet. | Sans objet. Aucun éditeur au-dessus de vous. |
| Si votre développeur part | Sans objet. | Le risque principal, et il est sous-estimé. | Le code est documenté, testé et repris par une équipe. |
| À qui appartient le code | À l'éditeur. Vous louez. | À vous. | À vous. |
| Où vivent vos données | Où l'éditeur les met. | Chez vous. | Où vous décidez. Hébergement québécois par défaut. |
| Comment vous sortez | Export dans un format à négocier. | Vous êtes déjà sorti. | Le dépôt et une copie complète de la base. |
Nos limites
Quand ce n'est pas nous, on vous le dit
Achetez du marché si votre produit tient dans un catalogue d'options stable, si vos règles ressemblent à celles de votre industrie, et si vous acceptez d'adapter légèrement votre façon de faire au moteur. Ce sera moins cher et plus rapide. On peut même vous aider à choisir et à le faire adopter, sans le bâtir.
Bâtissez à l'interne si vous avez déjà une équipe de développement, et si le configurateur est le cœur de votre produit plutôt qu'un outil de vente. Gardez-le chez vous, et venez plutôt nous voir pour les barrières à mettre autour.
Parlez-nous si votre métier ne rentre dans aucun moteur standard, que vous n'avez pas d'équipe de développement, et que le devis est ce qui vous fait gagner ou perdre des contrats.
On peut trancher ça en une conversation
Envoyez-nous un devis réel. Dans bien des cas, il suffit de le regarder pour savoir de quel côté vous tombez.
Votre devis ne sert qu'à bâtir votre exemple. Jamais montré à un tiers, jamais cité en référence sans votre accord écrit.