Outil sur mesure ou SaaS : comment l’IA change le calcul du build or buy

Logiciel sur mesure vs SaaS : pour une fonction standard ou réglementée (comptabilité, paie, messagerie), l’abonnement reste presque toujours le bon choix. Pour un processus qui vous différencie, qui relie plusieurs outils ou dont la facture par utilisateur grossit plus vite que l’usage, le sur-mesure redevient compétitif, car les agents de code ont fait baisser son coût de construction. Dans les deux cas, décidez sur un coût total à trois et cinq ans, et ne faites construire que ce que vous posséderez vraiment.

Longtemps, le « buy » a gagné par défaut dans les PME : construire coûtait trop cher et prenait trop de temps. L’IA rebat une partie des cartes, pas toutes. Voici ce qui a changé, les cas où chaque option l’emporte, un calcul de coût complet (fictif, hypothèses à l’appui), les risques du développement sur mesure et la façon de les neutraliser, puis une grille pour trancher outil par outil.

Build or buy : qu’est-ce que l’IA a changé ?

Le coût d’un logiciel sur mesure, c’est d’abord du temps de développement. Or une application métier est faite, pour l’essentiel, de briques connues : des écrans et des formulaires, une base de données, des droits d’accès, des connecteurs vers d’autres outils, des exports, des tests. C’est précisément ce que les agents de code (Claude Code, Codex, GitHub Copilot, Cursor) produisent désormais vite, sous le contrôle d’un développeur qui découpe le travail, relit et teste. Nous détaillons cette façon de travailler dans notre article sur le développement assisté par IA.

Conséquence : le ticket d’entrée du sur-mesure a baissé. C’est la thèse que nous résumons par « louer → posséder ». Au lieu d’empiler des abonnements facturés par tête, chaque mois, sans date de fin, une PME peut faire construire un outil qui épouse son métier et qui lui appartient. Notre méthode vise un premier prototype utilisable en quelques semaines, enrichi ensuite par itérations courtes. Le gain varie selon les équipes et reste difficile à mesurer précisément : il est net sur les briques standard d’une application métier, beaucoup moins sur un code ancien et complexe.

L’IA ne change pourtant qu’un terme de l’équation. Elle réduit le coût de construction ; elle ne supprime ni l’hébergement, ni les mises à jour de sécurité, ni les évolutions, ni le temps que vos équipes passent à préciser le besoin et à valider le résultat. Méfiez-vous de la promesse d’un « coût récurrent nul » : un outil sans budget de maintenance devient vite une dette. Ce qui change vraiment, c’est le point d’équilibre. Parce que construire coûte moins cher, le sur-mesure devient rentable plus tôt, pour des équipes plus petites et sur des périmètres plus modestes.

Second changement, moins visible : un outil sur mesure peut embarquer l’IA au cœur de votre processus, branchée sur vos données. Un agent IA qui prépare les devis selon vos règles, lit les documents entrants ou relance les clients ne figure au catalogue d’aucun SaaS généraliste. L’éditeur vous vendra l’IA de sa feuille de route, pas celle de votre métier.

Quand le SaaS reste-t-il le meilleur choix ?

Acheter reste la bonne décision chaque fois que la fonction est la même pour toutes les entreprises, et plus encore quand elle est réglementée.

• Comptabilité et paie. La paie cumule conventions collectives, déclaration sociale nominative (DSN) et barèmes révisés chaque année. Un éditeur spécialisé absorbe ces évolutions pour des milliers de clients ; reconstruire ces logiciels n’a aucun sens pour une PME.
• Facturation électronique. Depuis le 1er septembre 2026, toutes les entreprises doivent pouvoir recevoir leurs factures sous forme électronique, et l’obligation d’émettre s’étend aux PME et aux micro-entreprises le 1er septembre 2027 (impots.gouv.fr). Ces flux passent par des plateformes agréées par l’administration fiscale. Votre outil sur mesure peut s’y connecter ; il ne doit pas les remplacer.
• Messagerie, bureautique, visioconférence. Ce sont des outils mondiaux, interconnectés, sécurisés par des équipes que vous n’aurez jamais. Leur prix bouge : au 1er juillet 2026, Microsoft a relevé le prix catalogue de Microsoft 365 Business Standard de 12,50 à 14 dollars hors taxes par utilisateur et par mois, soit +12 % (grille publique en dollars, consultée en septembre 2026 ; les prix varient selon les pays). Aucune PME n’a pour autant intérêt à reconstruire sa messagerie.
• Les besoins urgents ou exploratoires. Si vous devez être opérationnel la semaine prochaine, ou si le processus n’est pas encore stabilisé, un SaaS permet d’apprendre sans investir. Vous construirez plus tard, avec un cahier des charges nourri par l’usage réel.
• L’absence de responsable interne. Un outil sur mesure a besoin d’un propriétaire côté métier qui arbitre les évolutions. Sans lui, prenez l’abonnement.

Une règle simple : si un éditeur sérieux vend exactement votre processus à des milliers d’entreprises, ce processus n’est probablement pas votre avantage concurrentiel. Achetez.

Quand le développement sur mesure l’emporte-t-il ?

Construire devient pertinent quand plusieurs des signaux suivants se cumulent.

Sur les données, le sur-mesure vous laisse choisir l’hébergement. Nous hébergeons ainsi les applications que nous développons sur l’infrastructure de Scaleway, un hébergeur français ; les enjeux sont détaillés dans notre article sur l’IA souveraine.

Dans les faits, la réponse est rarement binaire. La configuration la plus robuste, à notre avis, garde les SaaS standard (comptabilité, messagerie) et construit une couche sur mesure qui les relie : un outil métier qui lit et écrit dans ces SaaS par leurs API, et qui porte le processus qui vous est propre.

Combien coûte chaque option sur 3 à 5 ans ? Un exemple chiffré

Prenons une PME fictive de 80 personnes qui gère ses chantiers dans un SaaS métier utilisé par 40 salariés. Elle se demande si elle doit le remplacer par un outil sur mesure. Les chiffres ci-dessous sont des hypothèses de travail, pas des prix de marché : remplacez-les par les vôtres.

Coût cumulé, en euros hors taxes :

À trois ans, les deux options se valent, le SaaS restant un peu moins cher. Le point d’équilibre arrive au cours de la quatrième année. À cinq ans, le sur-mesure coûte environ 33 000 € de moins, soit près de 20 %. Mais ce résultat bascule vite quand on touche aux hypothèses :

• Avec 15 utilisateurs, le SaaS coûte environ 80 000 € sur cinq ans : il l’emporte largement.
• Avec 80 utilisateurs, il dépasse 315 000 €, quand le sur-mesure reste sous 160 000 € même en doublant l’hébergement.
• Sans hausse annuelle de l’abonnement, le SaaS revient à 157 000 € sur cinq ans : le sur-mesure garde un avantage d’environ 19 000 €.
• Si la maintenance coûte 30 % de la construction par an au lieu de 20 %, le sur-mesure atteint 168 000 € : l’écart disparaît presque.

Ce que le calcul ne montre pas : le temps interne (administrer un SaaS d’un côté, piloter les évolutions de l’autre), le coût des appels aux modèles d’IA si l’outil en embarque, le risque de dépassement du projet et, surtout, la valeur créée par un processus mieux outillé. Pour les postes de coûts, voyez combien coûte un projet IA ; pour chiffrer les gains, notre méthode de calcul du ROI. C’est sur la ligne « construction », et dans une moindre mesure sur la maintenance, que l’IA agit : chaque baisse rapproche le point d’équilibre.

Quels sont les risques du sur-mesure, et comment les neutraliser ?

La maintenance oubliée

Un logiciel vit : bibliothèques à mettre à jour, failles à corriger, API tierces qui changent. Budgétez dès le départ un forfait annuel de maintenance (20 % du coût de construction dans notre exemple : un ordre de grandeur, pas une norme), exigez des tests automatisés et une supervision avec alertes, et fixez par contrat les délais de correction.

La dépendance au prestataire

Le vrai risque du sur-mesure est moins technique que contractuel, et il se joue dès le choix du prestataire. Trois protections ne se négocient pas.

1. La propriété, par écrit. En droit français, le logiciel créé par vos salariés dans l’exercice de leurs fonctions vous revient automatiquement (article L113-9 du Code de la propriété intellectuelle). Celui d’un prestataire, d’un freelance ou d’une agence, non : il faut un contrat de cession de droits écrit, qui mentionne chaque droit cédé et en délimite l’étendue, la destination, le lieu et la durée (article L131-3). L’Agence pour la protection des programmes détaille ces mentions.
2. La possession, dès le premier jour. Le dépôt de code dans votre organisation GitHub ou GitLab ; les comptes d’hébergement, les noms de domaine et les clés d’API à votre nom. Le prestataire y travaille en invité, pas l’inverse.
3. La documentation dans le dépôt. Spécifications, décisions d’architecture, procédures d’installation et d’exploitation, versionnées avec le code et mises à jour à chaque livraison. C’est ce qui permet à un autre prestataire de reprendre l’outil, et aux agents de code de travailler juste.

Une question juridique reste débattue : la protection par le droit d’auteur d’un code largement généré par une IA. Raison de plus pour ne pas compter uniquement sur la cession de droits et pour sécuriser la possession effective du code.

La réversibilité, testée

Écrivez une clause de réversibilité (export des données dans un format ouvert, assistance à la reprise, délais), puis testez-la : demandez à un développeur extérieur au projet d’installer l’outil à partir de la seule documentation. S’il n’y parvient pas en quelques jours, la documentation n’est pas terminée.

Côté SaaS, le Data Act (règlement (UE) 2023/2854), applicable depuis le 12 septembre 2025, oblige les fournisseurs de services de traitement de données, SaaS compris, à faciliter le changement de fournisseur : préavis de deux mois au plus, période de transition limitée à trente jours, et plus aucun frais de changement à compter du 12 janvier 2027. Son article 31 écarte toutefois une partie de ces obligations pour les services conçus sur mesure pour un client : pour votre outil, c’est le contrat qui fait la réversibilité. Un projet européen de simplification, en discussion au moment où nous écrivons (septembre 2026), pourrait par ailleurs assouplir certaines de ces règles.

Le code vite écrit, mais fragile

Un outil construit rapidement avec des agents de code peut accumuler de la dette : code dupliqué, cas limites non testés. Trois règles permettent de la contenir : chaque modification passe par une pull request relue par un humain, les tests automatisés tournent à chaque changement, la branche principale est protégée. Et avant d’industrialiser, validez l’usage sur un prototype, comme nous le décrivons dans du POC à la production.

La grille de décision : 10 questions pour trancher

Deux questions éliminatoires d’abord. La fonction est-elle standard et réglementée (paie, comptabilité, facturation électronique) ? Prenez un SaaS. Personne côté métier ne peut consacrer quelques heures par semaine au projet ? Prenez un SaaS, ou attendez.

Notez ensuite chaque question de 0 à 2 points.

Lecture du score :

• De 0 à 7 : SaaS. Optimisez plutôt vos abonnements (licences inutilisées, niveau d’offre adapté).
• De 8 à 13 : hybride. Gardez le SaaS comme socle et construisez la couche qui manque : connecteurs, tableau de bord, agent IA.
• De 14 à 20 : sur mesure. Chiffrez l’option sur trois et cinq ans, puis lancez un prototype.

Cette grille ne remplace pas le calcul : elle indique où le faire en premier.

Par où commencer pour remplacer ses SaaS ?

1. Inventorier la pile. Pour chaque abonnement : coût annuel, licences payées et réellement utilisées, outils qu’il alimente, données qu’il détient.
2. Choisir un candidat. Pas le plus gros : le plus douloureux et le mieux délimité. Typiquement, un outil métier cher par utilisateur, mal relié au reste et contourné par des tableurs.
3. Chiffrer les deux options sur trois et cinq ans, avec la méthode ci-dessus et vos propres hypothèses.
4. Prototyper sur vos données réelles, avec les utilisateurs, en quelques semaines.
5. Faire tourner en parallèle, migrer les données, puis résilier l’abonnement une fois l’adoption acquise. Vérifiez les préavis de résiliation avant de lancer le chantier.

Cet inventaire est souvent la première étape d’un audit IA : cartographier les outils et les flux avant de décider quoi garder, quoi relier et quoi construire. Quand la décision penche vers le sur-mesure, notre offre de développement suit ce chemin, du cadrage à la maintenance, et vous restez propriétaire de ce qui est développé.