Logiciel sur mesure ou logiciel standard : comment décider en entreprise

Un logiciel sur mesure n’est ni meilleur ni moins bon qu’un logiciel standard. Il répond à une autre question — et la plupart des mauvaises décisions en la matière viennent d’une entreprise qui se la pose une seule fois, pour tout à la fois.

En réalité, la question se tranche séparément pour chaque fonction. La messagerie, la comptabilité ou l’agenda n’ont rien à voir avec le processus qui distingue votre entreprise de ses concurrents, ou avec celui qui rassemble des données venues de plusieurs endroits. Dans une entreprise type, certains outils valent la peine d’être loués pendant des années, tandis qu’une ou deux pièces valent la peine d’être construites.

Nous écrivons depuis les deux côtés de la décision. Nous développons des logiciels métier sur mesure pour nos clients, mais le site que vous lisez est lui-même un exemple de ce partage : une partie tourne sur des services pour lesquels nous payons un abonnement, une autre partie, nous l’avons écrite nous-mêmes. Nous montrons ci-dessous ce qui est allé où et pourquoi, puis nous en tirons des critères applicables à votre entreprise — avec un calcul du coût total de possession sur cinq ans et la manière de ne pas devenir dépendant d’un fournisseur, quelle que soit la voie choisie.

Ce qu’est un logiciel sur mesure, et ce qu’est un logiciel standard

Un logiciel standard est un outil qui existe déjà et qui se vend à de nombreuses entreprises à la fois — le plus souvent sous forme d’abonnement (SaaS), parfois avec une licence unique. Vous vous connectez et vous l’utilisez : un CRM, un logiciel de facturation, un outil de prise de rendez-vous, une plateforme de commerce en ligne. L’éditeur décide de son évolution, et vous recevez ce que reçoivent tous ses clients.

Un logiciel sur mesure — on parle aussi de logiciel personnalisé ou, pour un outil isolé, d’application sur mesure — est un système construit autour de la façon de travailler d’une entreprise. Il peut s’agir :

• d’un système de prise de commandes et de suivi de leur exécution,
• d’une application qui planifie le travail des équipes sur le terrain,
• d’un portail client avec l’historique de la relation,
• d’un configurateur de produits qui facilite la vente de commandes inhabituelles,
• d’un petit module qui fait une seule chose qu’aucun outil standard ne fait comme il faut.

Entre ces deux pôles, deux voies intermédiaires méritent d’être gardées en tête dès le départ. La première, ce sont les outils low-code et les automatisations (Make, Zapier, Airtable), qui permettent de relier des services existants sans écrire un système complet. La seconde, c’est l’approche hybride : des outils standard pour ce qui est standard, plus un module à vous là où le standard s’arrête. Nous reviendrons sur les deux.

Un point que les offres mentionnent rarement : « sur mesure » ne veut pas automatiquement dire « à vous ». Que le code vous appartienne ou non dépend du contrat — et le sujet a sa propre section plus bas.

Comment nous avons tranché chez nous

Nous partons de notre propre cas, parce que nous en connaissons non seulement le résultat, mais aussi les raisons.

Le tableau fait apparaître le critère que nous appliquions sans savoir encore le nommer : nous louons ce qui est pareil dans toutes les entreprises, et nous construisons là où nos propres données et nos processus se rejoignent. Un agenda est un produit de base. Mais le moment où quelqu’un réserve un appel fait partie, pour nous, de l’histoire de ce contact : d’où il vient, ce qu’il a calculé auparavant dans le calculateur, sur quelle annonce il a cliqué. Un outil de réservation standard nous donnerait le rendez-vous, et il faudrait recoudre cet historique à la main.

Notre propre CRM — et ce que nous n’y avons volontairement pas mis

Notre CRM conserve l’attribution — l’identifiant du clic publicitaire, les paramètres de campagne, la première et la dernière visite — ainsi que les consentements et le circuit de suppression des données sur demande. De là, nous exportons vers Google Ads les conversions qui ont eu lieu hors du site, par exemple un appel téléphonique après un clic sur une annonce. Ce lien serait impossible si les données de contact se trouvaient dans le système de quelqu’un d’autre et les données de clic dans le nôtre.

Ce que nous n’avons pas construit est tout aussi instructif. La première version comportait une couche distincte pour les entreprises — nous l’avons retirée, parce que rien ne s’en servait. Elle n’est revenue que lorsque la synchronisation des boîtes mail a commencé à reconnaître l’entreprise d’après le domaine de l’adresse électronique, autrement dit lorsqu’une vraie raison est apparue. Le sur-mesure pousse à construire d’emblée tout ce qui pourrait servir un jour — et c’est la façon la plus coûteuse de s’en servir.

Une décision où le prix n’a joué aucun rôle

La décision la plus intéressante portait sur la connexion de nos boîtes mail au CRM. Il existe sur le marché des intermédiaires qui proposent une seule API pour Gmail et Outlook. À notre échelle, leur abonnement aurait été négligeable. Nous avons pourtant construit la connexion nous-mêmes, et dans la note consacrée à cette décision nous l’avons écrit noir sur blanc : le prix n’a jamais été l’argument. Les arguments étaient les suivants :

• l’intermédiaire devient sous-traitant de notre correspondance avec les clients — avec un contrat de traitement des données, une mention dans la déclaration de confidentialité et, pour les prestataires établis hors de l’UE, une évaluation du transfert de données ;
• l’étendue de l’accès — l’intermédiaire détient la clé de toute la messagerie de l’entreprise, offres et négociations comprises, et non d’« un peu de métadonnées » ;
• la dépendance envers un petit fournisseur sur un chemin critique du système ;
• un plafond pour notre propre logique — nos règles qui écartent les messages automatiques s’appuient sur des en-têtes que la couche de l’intermédiaire peut tout simplement masquer.

Et une ligne que nous jugeons la plus importante : la condition à laquelle la décision doit être rouverte. Si nous devions un jour synchroniser les boîtes mail de nos clients plutôt que les nôtres, chacun de ces arguments basculerait en faveur de l’intermédiaire. Une bonne décision entre acheter et construire porte une telle condition écrite dès le départ.

Quand un logiciel standard suffit — et vaut mieux

Les outils standard ont un avantage que rien ne remplace : ils fonctionnent tout de suite, quelqu’un d’autre s’occupe des mises à jour, des sauvegardes et de la sécurité, et si un outil ne convient pas, vous en changez sans perdre un investissement. Il reste d’ailleurs beaucoup à faire avec les seuls systèmes du marché. Dans l’enquête européenne qui le mesure, plus l’entreprise est petite, moins elle utilise ne serait-ce qu’un ERP ou un CRM standard. La Suisse ne fait pas partie de cette enquête, nous ne donnons donc aucun pourcentage suisse, mais la leçon ne dépend pas du chiffre : avant de construire, vérifiez si ce qui vous manque n’est pas tout simplement un système disponible sur le marché.

Dans trois situations, construire quoi que ce soit est tout simplement le mauvais choix.

Vous êtes à un stade très précoce. Si l’offre change tous les quelques mois et que le modèle économique est encore en test, un système à vous inscrira dans le code des hypothèses dépassées six mois plus tard.

Votre processus est standard dans votre secteur. Facturation, CRM simple, communication d’équipe, vente par une boutique classique — le marché regorge d’outils qui le font bien et qui évoluent plus vite que n’importe quelle entreprise ne ferait évoluer son propre équivalent.

Personne ne peut l’entretenir, et les processus ne sont pas stabilisés. Un système à vous a besoin d’un gardien, dans l’équipe ou chez le prestataire. Et si chacun dans l’entreprise fait la même chose un peu différemment, il faut d’abord mettre de l’ordre : un logiciel sur mesure fige un processus dans le code, y compris un mauvais.

Dans ces situations, plutôt que de construire, tournez-vous vers :

• un ensemble d’outils simples : Notion, Google Workspace, Trello, ClickUp,
• des automatisations qui relient des services existants : Zapier, Make, Airtable,
• des logiciels métier standard — CRM, ERP, systèmes de réservation conçus pour un secteur précis,
• un prototype fait d’un formulaire et d’un tableur, qui permet de tester le déroulement avant que quiconque écrive une ligne de code.

Ce dernier point est sous-estimé. Un formulaire de commande relié à un tableur et utilisé pendant quelques mois montre quelles étapes sont vraiment nécessaires et lesquelles ne semblaient importantes qu’au stade de la planification. Si le moment de construire arrive ensuite, vous passez commande en connaissance de cause, et non sur une intuition.

Quand un logiciel standard cesse-t-il de suffire ?

Un logiciel standard cesse de suffire lorsque contourner ses limites coûte plus de temps et d’argent que de l’utiliser. Cela se voit généralement à trois symptômes : quelqu’un recopie à la main des données d’un système à l’autre, l’équipe tient des tableurs de contournement à côté du système, et l’entreprise paie des licences et des fonctions dont elle ne se sert pas, parce que celle dont elle a besoin ne figure dans aucune formule.

En détail, les signaux sont les suivants :

• les mêmes données sont saisies à deux ou trois endroits — la commande dans la boutique, puis dans un tableur, puis dans la comptabilité,
• l’équipe contourne le système, parce que le processus ne correspond pas aux hypothèses de l’outil, et les tableurs reviennent « au cas où »,
• vous payez des licences inutilisées — une formule supérieure achetée pour une seule fonction, ou des postes pour des personnes qui se connectent une fois par mois,
• chaque service sait autre chose, parce que la vente travaille dans un outil, la production dans un autre, et le client écrit sur un troisième canal,
• une nouvelle idée d’amélioration se heurte aux limites de l’outil, et non au budget ou au calendrier.

Le tableau typique : un patron qui a « tout ce qu’il faut » — un CRM, la facturation, un système de tickets. Sauf que chacun de ces outils vient d’un monde différent, qu’il y a plusieurs identifiants et plusieurs endroits où quelque chose peut passer entre les mailles, et que le patron passe plus de temps à faire tenir les systèmes ensemble qu’à diriger l’entreprise. Ce n’est pas un argument pour tout jeter. C’est le signal qu’il vaut la peine de chercher l’endroit où les données divergent — et c’est généralement là que se trouve la première pièce qui mérite d’être construite.

Acheter ou développer : quatre questions qui tranchent

Au lieu du général « avons-nous besoin d’un logiciel sur mesure ? », posez quatre questions — séparément pour chaque fonction envisagée.

Ce processus est-il celui de votre secteur, ou le vôtre ?

Si vous faites quelque chose comme tout votre secteur le fait, un outil standard s’en chargera presque certainement. Si votre manière de prendre une commande, de chiffrer un produit inhabituel ou de servir un client est précisément ce qui vous distingue, un outil standard vous obligera à vous aligner sur la moyenne. Le test est simple : un client remarquerait-il la différence si vous faisiez comme tout le monde ? Sinon, c’est un processus de secteur.

Cette fonction réunit-elle des données de plusieurs endroits ?

Chez nous, c’est la question qui a le plus souvent fait pencher la balance. Si une fonction vit seule, louez-la. Si sa valeur tient à la réunion d’informations venues de plusieurs endroits — la commande avec le stock, le prospect avec l’annonce, le ticket avec l’historique du client —, c’est précisément ce lien qui est candidat au développement sur mesure.

Que coûtera l’abonnement pour l’équipe que vous prévoyez ?

La plupart des outils standard facturent par utilisateur ou par palier de fonctions. À cinq personnes, c’est sans importance ; à trente, non. Calculez l’abonnement pour l’équipe que vous prévoyez dans trois ans, et non pour celle d’aujourd’hui.

Qui l’entretiendra — et qu’emporterez-vous en partant ?

Un système à vous a besoin de quelqu’un qui s’occupe du serveur, des mises à jour et de la sécurité — dans votre équipe ou chez le prestataire. Un système standard a besoin d’un plan de sortie : dans quel format vous récupérerez les données et ce qui restera chez l’éditeur. Si personne dans l’entreprise ne sait répondre, notez-le comme un risque — nous y revenons à propos de la dépendance au fournisseur.

Si vous hésitez encore après ces questions, faites le quiz « SaaS prêt à l’emploi ou logiciel sur mesure ? ». Sept questions sur l’avantage concurrentiel, le budget, les délais, l’équipe et les intégrations mènent à l’une de plusieurs recommandations — du SaaS prêt à l’emploi au développement, en passant par le SaaS avec intégrations et l’approche hybride.

Le coût total de possession sur cinq ans

L’erreur la plus fréquente dans cette décision consiste à comparer un abonnement mensuel avec un prix de développement unique. Ce sont deux chiffres différents, qui décrivent des périodes différentes. Ce qu’il faut comparer, c’est le coût total de possession, ou TCO — tout ce que vous dépenserez pour une fonction donnée sur le même horizon, et pas seulement le prix de départ.

Du côté du logiciel standard, le TCO se compose de l’abonnement multiplié par le nombre d’utilisateurs et de mois, des suppléments pour les formules supérieures et les modules complémentaires, du coût des automatisations qui comblent les lacunes, et du coût de la sortie — le déménagement des données le jour où l’outil ne suffit plus.

Du côté du logiciel sur mesure : le développement, puis la maintenance courante — le serveur, les mises à jour, les corrections — et l’évolution, parce qu’un système appelé à servir des années sera modifié.

Les 360 CHF par mois qu’on oublie

Chez nous, la part fixe du TCO d’une application web sur mesure est de 360 CHF par mois : 300 CHF de maintenance et 60 CHF de serveur. Les offres comparent généralement les prix de développement, et ces 360 CHF n’apparaissent que sur la première facture après la mise en ligne. Sur cinq ans, cela fait 60 × 360 CHF, soit 21 600 CHF — pas très loin de ce que coûte le MVP lui-même. Vous pouvez calculer vous-même ces deux postes dans le calculateur du coût de maintenance.

Nos prix, et pourquoi nous ne citons pas de médiane du marché

Dans notre calculateur du coût d’une application web, le point de départ d’un MVP — une première version avec un seul parcours clé — est de 25 000 CHF, et celui d’une application complète de 72 500 CHF. Chaque intégration avec un système externe (CRM, ERP, paiements) coûte au moins 4 000 CHF. Le calculateur donne son résultat avec une fourchette de ±15 %, et les prix de maintenance s’entendent hors TVA.

Nous ne les comparons pas à une « médiane du marché » suisse, parce que nous n’en avons pas mesuré, et convertir en francs le chiffre d’un autre pays produirait un nombre qui a l’air précis et ne mesure rien. Ce que nous avons appris de notre étude des prix des applications web en Pologne vaut en revanche sur n’importe quel marché : le même mot « MVP » recouvrait des périmètres très différents d’un prestataire à l’autre. Une médiane n’est pas un prix. Quand vous comparez des devis, demandez la liste des fonctions, pas le nom de la formule.

Le seuil de rentabilité

Le calcul le plus simple : le coût de développement divisé par l’économie mensuelle, c’est-à-dire la différence entre l’abonnement et les 360 CHF de maintenance. Pour un développement à 25 000 CHF (la dépense d’abonnement est une hypothèse à remplacer par votre propre chiffre, pas une donnée de marché) :

À titre de comparaison, le TCO de votre propre MVP sur les mêmes cinq ans est de 25 000 CHF plus 21 600 CHF, soit 46 600 CHF — sans aucune évolution. Quand la dépense d’abonnement est faible, un développement ne s’amortit pratiquement jamais, même s’il donne l’impression d’un « investissement pour des années ». Il ne commence à payer que lorsque les abonnements ont grossi avec l’équipe, ou lorsqu’il s’agit de quelque chose qu’aucun outil standard ne fait.

Le calcul fait deux simplifications. Il suppose que votre système remplace tout l’outil — en pratique, il n’en remplace souvent qu’une partie. Et il laisse de côté le temps que l’équipe récupère lorsqu’elle cesse de recopier des données ; chiffrez cette valeur à part, et prudemment. Pourquoi les devis pour le développement lui-même varient autant est un sujet en soi — et la meilleure défense reste une liste d’exigences écrite.

L’hybride : du standard là où tout est standard, du sur-mesure là où est l’avantage

Dans la pratique, c’est la voie du milieu qui l’emporte le plus souvent. Une application sur mesure n’a pas à tout remplacer : vous gardez l’outil standard pour ce qu’il fait bien, et vous construisez un module là où le standard s’arrête. L’ensemble se relie par une API, une automatisation ou une fine couche intermédiaire.

Deux exemples tirés de nos échanges avec des clients. Une entreprise de formation utilisait une plateforme de cours standard qui gérait bien les supports et les paiements, mais qui n’envoyait pas les attestations et ne rappelait pas aux participants leurs travaux comme l’entreprise en avait besoin. Plutôt que de changer de plateforme, on a ajouté un petit module qui ne faisait que ces deux choses. Une boutique Shopify voulait que chaque client reçoive, après un achat, un plan personnalisé d’utilisation du produit, établi à partir d’un court questionnaire. On a construit un service séparé qui générait ce plan en PDF et l’envoyait par e-mail — tandis que tout le reste continuait de tourner sur Shopify.

Notre propre cas est du même ordre. La messagerie reste en abonnement et demeure la source de vérité sur la correspondance — le CRM n’en reprend que les métadonnées, un court extrait et un lien vers le message, jamais le contenu complet ni les pièces jointes. L’agenda reste chez Google, et notre module se contente de lire les créneaux libres et d’y inscrire les nouveaux rendez-vous.

L’hybride a le plus de sens quand le budget est limité mais qu’un processus n’est bien géré par rien ; quand vous voulez tester une fonction unique avant de construire davantage autour ; et quand le problème tient à la liaison entre plusieurs outils plutôt qu’aux outils eux-mêmes. Dans ce dernier cas, commencez par l’article sur l’automatisation des processus — l’automatisation résout souvent le problème avant qu’il faille construire quoi que ce soit.

Le code, les données et la sortie — le vendor lock-in dans les deux sens

Le vendor lock-in, ou dépendance au fournisseur, désigne la situation où changer de fournisseur coûte si cher que cela devient pratiquement impossible. On en parle généralement à propos du SaaS : les données sont chez le prestataire, l’export est maigre et la grille tarifaire ne cesse de monter. Or la dépendance guette des deux côtés de cette décision. La question décisive est de savoir ce qui vous protège — et pour une entreprise suisse, la réponse est la même des deux côtés : le contrat. L’Union européenne a inscrit dans la loi des droits de sortie pour les clients du cloud ; en Suisse, il faut les négocier.

Face à un fournisseur SaaS : le règlement européen sur les données, et pourquoi il ne vous couvre pas

Depuis le 12 septembre 2025, le règlement sur les données (Data Act), règlement (UE) 2023/2854, accorde aux clients des services de traitement de données — le considérant 81 cite parmi eux le « logiciel à la demande (SaaS) » — des droits de sortie que le contrat doit refléter :

• un délai de préavis pour lancer le changement de fournisseur « qui ne dépasse pas deux mois » (art. 25, par. 2, point d),
• une « période transitoire maximale obligatoire de trente jours calendaires », pendant laquelle le contrat reste applicable et le fournisseur aide au déménagement (art. 25, par. 2, point a),
• une « spécification exhaustive » des données qui peuvent être portées, « y compris, au minimum, toutes les données exportables » (art. 25, par. 2, point e),
• aucuns frais de changement de fournisseur à compter du 12 janvier 2027, et jusque-là des frais réduits seulement, qui ne dépassent pas les coûts supportés par le fournisseur (art. 29).

Le règlement s’applique aux fournisseurs « quel que soit leur lieu d’établissement, fournissant de tels services à des clients dans l’Union » (art. 1, par. 3, point f). Une entreprise suisse qui achète pour son activité en Suisse n’est pas un client dans l’Union — que le fournisseur soit suisse, américain ou européen — et le droit suisse ne lui accorde pas de droits équivalents. La seule règle de portabilité, l’art. 28 de la loi sur la protection des données (LPD), appartient à la « personne concernée », c’est-à-dire à une personne physique (art. 5, let. b) : elle peut obtenir « les données personnelles la concernant qu’elle lui a communiquées ». Elle ne donne à une entreprise aucun droit sur ses données commerciales, ni sur un délai de préavis, une période de transition ou des frais de changement de fournisseur.

En Suisse, lisez donc la liste ci-dessus comme une liste de contrôle, et non comme une protection. Demandez ces quatre clauses dans le contrat avant de signer : quel préavis, quelle durée de transition, quelles données sortent et dans quel format, et combien coûtera le déménagement. Un fournisseur qui sert déjà des clients dans l’UE est tenu de leur offrir ces conditions, ce qui en fait une question légitime ; qu’il les accepte dans un contrat suisse, c’est ce qu’il faut vérifier avant de dépendre de lui, pas après. Et si un système sur mesure vous est livré comme service dans le cloud du prestataire, écrivez les conditions de sortie avec le même soin.

À qui appartient le code source : face à un prestataire, seul le contrat vous protège

Le droit suisse règle un cas d’office. Selon la loi sur le droit d’auteur (LDA), « l’employeur est seul autorisé à exercer les droits exclusifs d’utilisation sur le logiciel créé par le travailleur dans l’exercice de son activité au service de l’employeur et conformément à ses obligations contractuelles » (art. 17). Pour un prestataire externe, il n’existe pas de règle de ce genre. Les droits restent à celui qui a écrit le code tant qu’un contrat ne les transfère pas.

En Suisse, « les droits d’auteur sont cessibles » (art. 16, al. 1) — mais « sauf convention contraire, le transfert d’un des droits découlant du droit d’auteur n’implique pas le transfert d’autres droits partiels » (art. 16, al. 2), et le transfert de la propriété d’un exemplaire de l’œuvre n’emporte pas celui des droits d’auteur (art. 16, al. 3). Un contrat qui dit « le prestataire remet l’application » sans nommer ce qui est transféré peut vous donner nettement moins que vous ne le pensez.

Pour un logiciel, le droit clé est celui de le modifier. L’auteur a le droit exclusif de décider « si, quand et de quelle manière l’œuvre peut être modifiée » (art. 11, al. 1, let. a). Sans ce droit dans votre contrat, un autre prestataire ne peut pas légalement faire évoluer votre système — et c’est le vendor lock-in à l’état pur, simplement de l’autre côté.

Licence logiciel ou cession des droits

La LDA ne fixe ni durée ni territoire par défaut pour une licence, et elle ne prescrit pas elle-même de forme pour le contrat. C’est une raison d’être précis par écrit, pas une raison de s’en dispenser : ce que le contrat passe sous silence est exactement ce sur quoi vous vous disputerez le jour où vous voudrez changer de prestataire.

Une licence n’est pas forcément un mauvais choix — elle est souvent moins chère et suffit pour un module censé fonctionner plutôt qu’évoluer. Mais choisissez-la en connaissance de cause. Exigez que le contrat prévoie : soit la cession des droits dont vous avez besoin — utiliser, modifier, faire évoluer et confier ces travaux à un autre prestataire —, soit une licence qui énumère ces mêmes utilisations avec son territoire et sa durée ; la remise du code source, de la documentation et des accès au dépôt et aux serveurs ; et le droit applicable au contrat. Les bibliothèques open source sur lesquelles repose tout système — le nôtre, par exemple, sur Payload CMS, Next.js et React, sous licence MIT — restent soumises à leurs propres licences ; le prestataire doit pouvoir en dresser la liste.

Par où commencer si la réponse est de développer

Choisissez le plus petit module qui réunit des données — une fonction qui résout le problème le plus important, au lieu d’un système complet. Le meilleur candidat est généralement l’endroit où quelqu’un recopie aujourd’hui des données à la main : l’effet s’y voit dès le premier jour et le risque y est le plus faible. Traitez ce module comme une première version avec un seul parcours clé, et résistez à l’envie d’y ajouter ce qui n’est pas sur ce parcours.

Écrivez les exigences en langage courant et essayez deux ou trois outils standard. La liste de ce qui leur manque est la meilleure spécification que vous puissiez remettre à un prestataire.

Inscrivez la sortie dans le contrat avant de commencer. Cession ou licence, utilisations autorisées, code source, documentation — et la condition à laquelle vous reverrez la décision.

Demandez un devis sur la base d’une liste d’exigences, pas « combien coûte une application ». Sans périmètre, vous obtiendrez des chiffres impossibles à comparer. Vous pouvez estimer un coût indicatif dans le calculateur d’application web ; demandez à chaque prestataire de vous présenter sa démarche, de l’analyse à la mise en ligne, avant de comparer les prix.

Si vous cherchez un prestataire, voyez comment nous abordons le développement de logiciels sur mesure — systèmes internes, intégrations, portails clients. Et si ce qui vous manque, c’est quelqu’un qui prenne la responsabilité des décisions elles-mêmes, nous vous accompagnons par du conseil technologique.

D’où viennent ces chiffres

• Prix de développement et de maintenance — les nôtres, issus de la configuration du calculateur du coût d’une application web et du calculateur du coût de maintenance, à la date du 22 septembre 2026 (prix de maintenance hors TVA) ; le calculateur donne son résultat avec une fourchette de ±15 %.
• Seuil de rentabilité et TCO — arithmétique sur des dépenses d’abonnement supposées, présentées dans le texte comme des hypothèses et non comme des données de marché.
• Entreprises équipées d’un ERP et d’un CRM — aucun chiffre suisse : la Suisse ne fait pas partie de l’enquête d’Eurostat sur l’intégration électronique des entreprises (« E-business integration »), dont provient la tendance décrite dans le texte.
• Droit — la loi fédérale sur le droit d’auteur (RS 231.1, état le 1er juillet 2025), la loi fédérale sur la protection des données (RS 235.1, état le 7 juillet 2025, art. 28) et, comme point de référence pour les clauses contractuelles, le règlement (UE) 2023/2854, lus à la source le 22 septembre 2026.
• Notre partage des outils — l’état du système sur lequel tourne ce site, et nos notes de décisions de conception.