Les repères de coût d'avant 2023 ne décrivent plus la réalité du sur-mesure. Un projet circonscrit se règle aujourd'hui en quelques soirées de dialogue avec un assistant de code ; un chantier qui touche plusieurs systèmes existants continue de se compter en semaines, parfois en mois. Ce qui a changé, c'est le temps d'écriture du code — pas le temps qu'il faut pour l'intégrer, le migrer, le vérifier et le maintenir. Voici comment je raisonne, par palier, sans faux chiffre.
Pourquoi les repères d'avant 2023 ne tiennent plus
Pendant quinze ans, l'argument qui justifiait presque tout abonnement logiciel tenait en une phrase : construire son propre outil coûtait des dizaines de milliers de francs et prenait des mois, avec un risque d'échec non négligeable. Cet argument reposait sur une réalité qui a bougé sur deux plans distincts depuis dix-huit mois.
Le premier changement touche l'écriture du code elle-même. Les assistants de développement réduisent radicalement le temps qui sépare une idée de son implémentation fonctionnelle. Je ne l'affirme pas dans l'abstrait : j'ai construit FiscalDoc, mon application locale de classement fiscal, en dialoguant avec un assistant de code plutôt qu'en l'écrivant ligne par ligne — trois soirées, pour un outil dont le coût d'exploitation est resté nul. Le récit complet est là.
Le second changement touche l'intelligence embarquée. Des modèles ouverts tournent désormais sur du matériel professionnel courant, sans appel à une API tierce facturée à l'usage. Ce qui exigeait hier un abonnement à un service cloud peut, pour une partie croissante des cas d'usage, s'exécuter localement — ce qui déplace à la fois le coût et la question de souveraineté des données, que j'ai posée en détail dans SaaS ou sur-mesure : louer ou posséder ses outils en Suisse. Quinze ans à superviser des budgets digitaux dans de grandes structures m'ont appris à me méfier d'un chiffre unique donné avant qu'une seule question n'ait été posée — c'est encore plus vrai aujourd'hui qu'hier.
Trois paliers, pas un chiffre unique
Un devis sérieux ne part jamais d'un prix ; il part d'un palier, puis affine. Voici les trois que j'utilise pour cadrer une conversation, avant tout chiffrage précis.
Le projet de quelques soirées. Un besoin circonscrit, porté par une seule personne qui connaît son sujet dans le détail, sans intégration à un système tiers ni utilisateur simultané à gérer. FiscalDoc en est l'exemple : quelques soirées de dialogue avec un assistant de code, et un coût d'exploitation resté nul une fois l'outil construit. Ce palier existe réellement, mais il reste rare en entreprise — la plupart des besoins professionnels impliquent plusieurs utilisateurs et au moins une connexion à un système existant.
Le projet de quelques semaines. Un outil métier qui sert une équipe entière sur un flux précis : un classement de documents partagé, un tableau de bord de pilotage, une automatisation d'un processus interne bien délimité. Il faut ici une interface pensée pour plusieurs utilisateurs, une phase de test au-delà de la tolérance d'une seule personne aux imperfections, et souvent une intégration simple à un outil déjà en place. L'enveloppe se compte alors en quelques milliers de francs, hors TVA, sur un horizon de semaines plutôt que de soirées.
Le chantier structurant. Un projet qui remplace un pan du système d'information : plusieurs intégrations avec des outils existants, migration de données historiques, exigences de sécurité et de conformité, plan de maintenance sur plusieurs années. Ce palier reste un vrai chantier, avec un horizon de mois et une enveloppe qui peut se compter en dizaines de milliers de francs, hors TVA. C'est précisément le type de projet que je cadre avec la grille de décision acheter ou s'abonner, dans le même mouvement que le cadrage de mes projets sur-mesure.
Ce qui n'a pas baissé : intégrations, migration, qualité, maintenance
Le temps d'écriture du code s'est effondré. Quatre autres postes, eux, n'ont pas bougé — et ce sont souvent eux qui déterminent le palier réel d'un projet.
Les intégrations. Connecter un nouvel outil à la comptabilité, à un ERP ou à une banque exige de comprendre les limites de leurs interfaces respectives, de gérer les cas d'erreur et de suivre leurs évolutions dans la durée. Un assistant de code accélère l'écriture de cette connexion ; il ne réduit pas le temps qu'il faut pour la vérifier, ni le nombre de systèmes tiers dont le comportement échappe à votre contrôle.
La migration des données. Sortir l'historique d'un abonnement SaaS pour l'installer dans un outil possédé suppose de nettoyer des formats hétérogènes, de reconstituer des liens entre fiches et de vérifier qu'aucune donnée ne s'est perdue en chemin. Ce travail reste largement manuel, quelle que soit la vitesse à laquelle le nouvel outil a été écrit.
La qualité. Un outil construit pour un seul usage tolère de petites aspérités qu'on corrige à la volée. Un outil dont dépendent plusieurs collaborateurs, des clients ou une obligation réglementaire ne tolère pas la même marge : tests, gestion des cas limites, revue de sécurité. Cette rigueur ne se raccourcit pas parce que la première version est arrivée vite.
La maintenance. Un outil possédé continue d'évoluer avec l'entreprise, exactement comme un abonnement continue de recevoir des mises à jour. La différence tient à qui en porte la charge. Livrer le code avec son propre outillage de maintenance assistée réduit ce coût dans la durée, sans le supprimer : quelqu'un doit rester capable de dialoguer avec cet outillage.
D'un palier à un chiffre
Aucun de ces trois paliers ne remplace un chiffrage réel : ce sont des ordres de grandeur pour cadrer une première conversation, pas un tarif. Le passage d'un palier à un chiffre suppose d'abord d'avoir tranché la question qui précède celle du coût — celle de savoir si l'outil doit être construit ou loué. Et pour une partie des outils d'une entreprise, la bonne réponse reste l'abonnement : je l'assume sans détour dans Dans quels cas garder son SaaS est le bon choix ?. Cette manière de cadrer, par palier puis par question, est celle que j'applique à chaque projet sur-mesure avant d'en écrire la moindre ligne. Pour situer cette décision dans l'ensemble des chantiers numériques d'une PME suisse, la feuille de route complète est posée dans Que doit faire une PME suisse face à l'IA en 2026 ?
Ce qu'il faut retenir
— Les repères de coût d'avant 2023 ne tiennent plus : l'écriture du code s'est effondrée en temps, pas les intégrations, la migration, la qualité et la maintenance. — Trois paliers cadrent une première conversation : projet de quelques soirées, projet de quelques semaines, chantier structurant — jamais un chiffre unique donné à l'aveugle. — Le palier réel se joue sur ce qui n'a pas bougé : nombre de systèmes à connecter, volume de données à migrer, niveau d'exigence de qualité, charge de maintenance.
FAQ
Un projet sur-mesure coûte-t-il aujourd'hui moins cher qu'un abonnement SaaS ? Cela dépend entièrement du palier et de l'horizon. Sur un besoin circonscrit et un horizon de plusieurs années, le sur-mesure devient souvent compétitif. Sur un besoin encore mouvant ou un horizon court, l'abonnement reste généralement la solution la moins chère.
Les assistants de code suppriment-ils le besoin de développeurs ? Non. Ils changent la vitesse à laquelle un besoin bien posé devient un outil fonctionnel, pas le besoin de comprendre l'architecture, de vérifier la qualité et de maintenir le résultat dans la durée. Le jugement reste humain ; l'exécution s'est accélérée.
Comment savoir dans quel palier se situe mon projet ? Comptez les systèmes existants à connecter, le nombre d'utilisateurs simultanés et l'ancienneté des données à reprendre. Plusieurs connexions, une dizaine d'utilisateurs ou un historique de plusieurs années font en général basculer un projet du palier « semaines » vers le palier « chantier structurant ».
Faut-il une équipe technique interne avant d'envisager le sur-mesure ? Pas nécessairement, à condition que le prestataire livre le code en pleine propriété avec un outillage de maintenance assisté par IA. L'entreprise reste alors autonome sans avoir à recruter une équipe de développement dédiée.
Un devis vous a déjà été donné sans qu'on pose vos flux réels ? Le Diagnostic d'Usage IA : soixante minutes pour poser vos flux réels, identifier ce qui mérite du sur-mesure, ce qui reste en SaaS, et ce qui n'a pas besoin d'IA du tout. Réserver un diagnostic
Jérôme Deshaie est CEO et fondateur de MCVA Consulting SA, agence augmentée basée en Valais. Quinze ans au service de grandes marques internationales, désormais en direct pour les PME suisses. Parcours.