Le prêt‑à‑porter logiciel optimise l'achat. Le sur-mesure optimise le métier.
Dans beaucoup d'organisations, la question revient toujours sous la même forme :
« Pourquoi développer sur mesure alors qu'on peut installer WordPress, WooCommerce, Odoo ou Prestashop ? »
L'argument est simple : c'est plus rapide, plus confortable, moins coûteux. Et c'est vrai… mais aussi sur la durée ?
Parce que le prêt‑à‑porter logiciel est confortable à l'acquisition, probablement pas à l'usage.
1. Le confort d'acquisition : un système prêt à l'emploi, mais pas prêt pour le métier
Installer un CMS ou un ERP générique, c'est comme acheter un costume sur Internet. On clique, on installe, on active deux plugins : ça fonctionne. On a un outil opérationnel en quelques heures.
Ce confort est réel : les briques sont déjà là, les moteurs sont intégrés, les workflows sont préconfigurés, l'écosystème est riche, la documentation est abondante.
Mais ce confort est celui de l'entrée dans le système. Il ne dit rien de la capacité de l'outil à représenter le métier réel.
Et c'est là que commence la dette invisible.
2. La dette invisible : quand le métier doit compenser en permanence
Un outil générique est conçu pour un métier générique. Or le métier réel n'est jamais générique.
Un livre et une carotte ont un seul point commun : ils se vendent. Pour tout le reste, ils n'ont rien à voir. Les workflows, les états, les contraintes, les dépendances, les invariants métier sont différents.
Pourtant, les outils génériques imposent un modèle mental unique. Résultat : c'est le métier qui doit compenser.
Il doit contourner les limites, ajouter des écrans, bricoler des plugins, réécrire des workflows, adapter des schémas, gérer des exceptions, corriger l'UX/UI pour "rattraper" l'outil.
Chaque exception métier devient un hack. Chaque évolution métier devient une dette. Chaque contrainte métier devient une friction.
Le confort d'acquisition crée une dette d'usage. Et cette dette grossit chaque jour : d'ailleurs vous l'entendez ce grognement dans les équipes.
3. Le coût d'usage : rigidité, contournements, et une économie de l'attaque qui change de nature
Le coût réel du prêt‑à‑porter n'est pas seulement financier. Il est structurel.
On hérite de schémas imposés, de workflows implicites, d'états intermédiaires non maîtrisés, de limitations structurelles, de plugins qui cassent, de mises à jour qui imposent des migrations, d'une UX/UI compensatoire pour "faire avec".
Ce que ces coûts ont en commun porte un nom en gestion : le TCO, le coût total de possession. C'est l'idée que le prix d'achat n'est qu'une fraction de ce que coûte réellement un outil sur sa durée de vie, une fois ajoutés la maintenance, les montées de version, la formation, le support, et le coût de sortie si on veut un jour en changer. Ce n'est pas propre au logiciel. Un outil de bricolage bon marché se répare mal, s'use vite, s'adapte mal à des situations de travail un peu spécifiques, quand l'outil de qualité, plus cher à l'achat, se répare et dure. Un vêtement premier prix ne se reprend pas, ne s'ajuste pas, se remplace prématurément, quand un vêtement bien coupé se répare et s'ajuste dans le temps. Une alimentation bon marché déplace son coût réel vers des dépenses de santé qui n'apparaissent jamais sur le ticket de caisse. Le logiciel prêt-à-porter obéit exactement à la même logique : le coût ne disparaît pas, il se déplace, de l'achat vers la maintenance, la sécurité, la formation, et le temps perdu à compenser ce que l'outil ne fait pas nativement. Le TCO du prêt-à-porter grimpe silencieusement, invisible au moment de l'achat, jusqu'à dépasser largement l'économie apparente qui a justifié le choix initial.
Mais il y a un coût encore plus sous‑estimé : la sécurité. Et c'est un point qui mérite d'être traité sérieusement, parce que l'objection inverse est légitime et qu'il faut la regarder en face plutôt que la balayer.
L'objection : ce n'est pas de la sécurité, c'est de l'obscurité
On pourrait m'opposer ceci : dire qu'un système sur-mesure serait plus sûr simplement parce qu'il est moins connu relève de la "security by obscurity", un raisonnement que la sécurité informatique rejette à juste titre depuis longtemps. Un code fait maison, sans revue par une communauté, sans CVE publiées, sans cadence de correctifs établie, peut receler des failles aussi graves qu'un CMS générique, avec une aggravation notable : personne ne les cherche, et elles ne seront découvertes que le jour de l'incident.
Cette objection est fondée. Elle porte sur la qualité intrinsèque du code, qui peut être bonne ou mauvaise dans les deux modèles, prêt-à-porter comme sur-mesure. Le sur-mesure n'est pas magiquement mieux écrit. Mais cette objection ne traite que d'une seule variable. Il en existe une seconde, qui pèse de plus en plus lourd : l'économie de l'attaque, c'est-à-dire ce que coûte une exploitation à l'attaquant, et ce que ça lui rapporte.
Le changement de nature du trafic web
Ce terrain a bougé récemment, et de façon spectaculaire. Selon le rapport Bad Bot 2026 de Thales/Imperva, le trafic automatisé représente désormais 53 % du trafic mondial sur Internet, contre 47 % pour l'activité humaine. Cloudflare, qui anticipait ce basculement pour 2027, a confirmé qu'il s'était produit dès mai 2026, avec un an d'avance sur ses propres prévisions. Une part croissante de ce trafic automatisé est désormais pilotée par l'IA : les agents capables de scraper, tester des identifiants et sonder des vulnérabilités connues opèrent à une échelle et une vitesse sans commune mesure avec un attaquant humain.
Ce basculement change la donne. Un CMS ou un ERP massivement diffusé documente nécessairement ses points d'entrée pour permettre plugins, thèmes, webhooks et connecteurs. Chaque point d'entrée documenté devient une signature exploitable, et cette signature est identique sur des dizaines de milliers d'instances du même logiciel dans le monde. Pour un bot, tester cette signature sur un parc entier ne coûte quasiment rien de plus que de la tester sur un seul site : c'est le principe même de l'automatisation à l'échelle. Les logs de n'importe quel WordPress modeste en témoignent, avec des milliers de tentatives par jour même sur des sites sans enjeu particulier.
Un système sur-mesure n'a pas cette signature reproductible. Ce n'est pas qu'il soit intrinsèquement mieux protégé au niveau du code : c'est qu'il ne figure pas sur la liste des cibles à haut rendement que l'automatisation économique privilégie structurellement. Attaquer un système sur-mesure exige une reconnaissance ciblée, propre à ce système, qui ne se réplique pas ailleurs. Attaquer un CMS générique, c'est écrire un script une fois et le lancer sur un parc entier.
Ce que cela signifie concrètement
La conséquence n'est pas que le sur-mesure dispense de discipline de sécurité. C'est l'inverse : un système qui n'est pas scanné en masse doit quand même être audité, parce que sa tranquillité relative face aux bots ne dit rien de sa robustesse face à un attaquant qui le ciblerait spécifiquement. Mais la nature du risque diffère. Le risque du prêt-à-porter est systémique et automatisable, il touche un logiciel, donc potentiellement tout son parc, à la vitesse et au coût d'un bot. Le risque du sur-mesure est artisanal, il exige un effort dédié par cible, ce qui le rend statistiquement moins probable dans un monde où la majorité du trafic malveillant fonctionne par réplication automatique, pas par ciblage individuel.
Ce n'est donc pas de la security by obscurity. C'est une différence dans l'économie de l'attaque : réduire la surface exploitable à l'échelle industrielle, dans un contexte où l'essentiel du trafic hostile est désormais généré par des machines qui raisonnent précisément à cette échelle.
4. La gouvernance des évolutions : confort réglementaire, perte de souveraineté
Il existe pourtant un vrai avantage au prêt‑à‑porter : quand une norme change, tout l'écosystème se met à jour.
C'est un confort énorme.
Mais ce confort a un revers : on adopte l'interprétation de l'éditeur.
On subit son calendrier, ses migrations, ses ruptures de compatibilité, ses choix de conception, ses arbitrages métier.
On gagne du confort réglementaire. On perd de la souveraineté métier.
Et dans les métiers où la donnée est l'actif principal, perdre du contrôle revient à augmenter le risque de rupture de continuité.
5. Le LVMH du code : quand le prix cesse d'être un signal de confiance
Il existe une tentation naturelle à comparer le sur-mesure logiciel à l'artisanat textile menacé par la délocalisation. L'analogie fonctionne, mais pas dans le sens où on l'imagine spontanément. Le risque n'est pas que le code se fasse demain dans un pays à bas coût plutôt qu'ici. Le risque est qu'il se fasse dans une IA plutôt que dans un atelier tracé, avec cette différence essentielle par rapport au textile : il n'y a plus de frontière, de délai d'expédition ni de contrat de sous-traitance visible pour matérialiser ce déplacement. Le glissement est instantané et invisible.
Il faut cependant se garder d'un raccourci : IA ne veut pas dire low-cost au sens de mauvaise qualité, et low-cost ne veut pas dire entrée de gamme. Ce sont deux axes indépendants. Une maison de haute couture qui fait fabriquer au Portugal ou en Tunisie ne dégrade pas sa gamme du simple fait que la main-d'œuvre y coûte moins cher : ce qui distingue le low-cost premium du low-cost entrée de gamme, c'est ce qui encadre la production, cahier des charges, contrôle qualité, responsabilité assumée sur le résultat. L'IA pousse ce découplage à son terme. Elle rend possible, à coût de production quasi nul, un résultat de haut niveau, à condition d'être encadrée avec la même rigueur qu'un atelier tracé.
Cela emporte une conséquence directe pour le client : le prix cesse de fonctionner comme signal de confiance. Historiquement, un client qui ne pouvait pas juger la qualité d'un code se rabattait sur un proxy imparfait mais universel, 'cher donc sérieux, pas cher donc bâclé'. Ce proxy s'effondre au moment précis où produire à bas coût un résultat de haut niveau devient possible. Un prestataire qui continuerait à signaler sa qualité par un tarif élevé se ferait rattraper par un concurrent produisant un résultat équivalent à moindre coût grâce à une IA bien gouvernée.
Le stack prêt-à-porter, WordPress ou Odoo, ne disparaît pas dans ce mouvement. Il change de destinataire. Les générateurs IA grand public ciblent déjà directement l'entrepreneur et la petite structure, pas l'agence. Ces stacks redeviennent ce qu'ils auraient toujours dû rester pour les besoins génériques : des outils que le métier opère lui-même, en DIY (Do it yourself), sans intermédiaire technique.
Dans ce paysage, un "LVMH du code" ne peut pas émerger de la simple discipline tarifaire d'un groupe de prestataires qui refuseraient de baisser leurs prix. Sans barrière à l'entrée, cette discipline collective s'effondre au premier acteur qui casse les prix pour prendre du marché : c'est un dilemme du prisonnier classique, celui qui a écrasé les marges du développement web générique depuis quinze ans. Ce qui peut réellement fonder un segment premium, c'est un signal de confiance qui ne dépend ni du prix payé à l'heure, ni de l'origine humaine ou IA du travail produit : une gouvernance documentée, vérifiable par un client qui ne saura jamais lire le code lui-même.
Cette gouvernance repose sur une posture à deux faces, et c'est précisément ce qui distingue le luxe du soupçon généralisé. Le luxe ne présume pas la faute. Il rend service, il fait confiance par défaut, c'est sa posture de base, celle qui fait la différence d'expérience avec un prestataire qui traite chaque client comme un fraudeur potentiel. Mais le luxe ne confond jamais confiance et naïveté : il se donne les moyens de vérifier, de contrôler, de s'assurer qu'on ne le prend pas pour un jambon (sauf à Aoste). La confiance accordée au client n'est pas un renoncement au contrôle, elle est justement ce qui permet de ne pas avoir à le brandir à chaque échange, parce qu'il existe en arrière-plan.
Concrètement, cette gouvernance se traduit par quatre engagements écrits. Une responsabilité assumée et assurée, matérialisée par une attestation de responsabilité civile professionnelle plutôt qu'une simple promesse orale. Des garanties bornées à un périmètre précis, portant sur les défauts du code livré à la date de livraison, pas sur l'obsolescence future d'une dépendance tierce. Un accompagnement dont le coût ne dépend pas du nombre de sollicitations, ce qui élimine la tentation du client de compter ses appels et celle du prestataire de sur-facturer chaque échange, rendu possible précisément parce que la relation reste à échelle humaine plutôt qu'industrielle. Et un droit de reprise documenté, garantissant qu'aucun client ne reste dépendant indéfiniment du prestataire d'origine : la vraie garantie premium n'est pas de rester disponible pour toujours, c'est de faire en sorte que le client n'ait jamais besoin que son prestataire le reste.
Aucun de ces quatre engagements ne repose sur le prix payé à l'heure ni sur l'origine humaine ou IA du travail produit. C'est précisément ce qui en fait un signal robuste dans un marché où ni l'un ni l'autre ne veut plus rien dire.
6. Conclusion : le prêt‑à‑porter optimise l'entrée dans le système, le sur‑mesure optimise la vie dans le système
Le prêt‑à‑porter logiciel est parfait pour les métiers génériques. Il est dangereux pour les métiers spécifiques, sensibles ou critiques.
Le sur‑mesure n'est pas un luxe. C'est une stratégie de continuité.
Ce n'est pas un sujet technique. C'est un sujet de gouvernance.
La vraie question n'est donc pas :
« Faut‑il réinventer la roue ? »
La vraie question est :
Qui doit s'adapter à qui ? Le métier à l'outil, ou l'outil au métier ?