Principaux enseignements

• La décision ERP-vs-SaaS n'est plus binaire en 2026. Les modèles d'IA et l'architecture multi-tenant ont suffisamment changé les deux catégories pour que la bonne réponse pour de nombreuses entreprises soit un hybride que j'ai rarement vu il y a cinq ans.

• Cinq questions déterminent la catégorie pour 90 % des clients que je rencontre. L'ancienneté de l'utilisateur, le poids du flux de travail interdépartemental, la pression réglementaire, l'écart entre l'acheteur et l'utilisateur, et le taux de changement du flux de travail. Les distinctions entre les marques ont moins d'importance.

• Six modèles d'interface utilisateur/utilisateur sont désormais la norme dans les deux mondes. La navigation basée sur l'intention, les copilotes ambiants, les défauts génératifs, les affordances de confiance, la personnalisation éphémère et les résumés d'audit.

• Sur nos 47 derniers projets audités, l'erreur la plus coûteuse n'a pas été le choix du fournisseur. C'est l'inadéquation des catégories. Les fondateurs qui ont choisi le mauvais type de système ont payé 2 à 3 fois plus que les fondateurs qui ont choisi le bon type de système avec un fournisseur médiocre.

La décision est devenue plus difficile, pas plus facile

Je voudrais commencer par un point qui semble contre-intuitif. La décision ERP versus SaaS est plus difficile à prendre en 2026 qu'elle ne l'était en 2020. Non pas parce que la technologie est devenue plus compliquée, bien que ce soit le cas. C'est parce que les catégories elles-mêmes se sont brouillées au point que l'ancienne terminologie a cessé de fonctionner.

Il y a cinq ans, je pouvais dire à un client de quel côté de la ligne se situait son entreprise en l'espace d'une heure. ERP pour le flux de travail approfondi, l'ancienneté de l'utilisateur, le flux de données interdépartemental. SaaS pour le produit ciblé, l'acheteur en libre-service, la cadence de publication rapide. Cette heuristique s'est brisée quelque part en 2024. Au moment où j'écris ces lignes, en avril 2026, j'ai livré un ERP multi-tenant qui fonctionne sur la même architecture que nos produits SaaS grand public, et j'ai livré un SaaS vertical qui fait le travail d'un système ERP de 400 000 dollars pour un quart du coût. Les catégories ne signifient plus ce qu'elles signifiaient.

La plupart des articles que j'ai lus récemment sur ce sujet sont des articles de classement des fournisseurs. Microsoft Dynamics contre NetSuite contre SAP. Ils ne sont pas inutiles, mais ils répondent à une question que presque personne ne se pose en réalité. La vraie question est de savoir s'il faut acheter un ERP, si votre entreprise est mieux servie par un SaaS vertical personnalisé, ou si ce dont vous avez vraiment besoin est un hybride qui n'entre dans aucune des deux catégories. Aucun de ces articles ne vous aidera à répondre à cette question. Je vais donc écrire l'article que j'aurais aimé que quelqu'un écrive pour moi il y a trois ans.

Pour situer le contexte, mon équipe et moi-même travaillons en tant que société de développement de logiciels d'ERP pour environ 30 % de nos engagements actifs et en tant que studio de produits SaaS pour les 70 % restants. Cette répartition est restée remarquablement stable pendant quatre ans, même si le travail lui-même a changé. Ce mélange me donne un point de vue que n'ont pas les ateliers purement ERP ou SaaS. Je vois comment les deux catégories convergent, et je vois où elles divergent encore, et je veux partager ce que j'ai appris.

Pourquoi "ERP ou SaaS" est de plus en plus la mauvaise question ?

Permettez-moi de vous donner la raison technique pour laquelle les catégories se sont brouillées, car elle est importante pour la logique de décision qui suit.

Pendant la majeure partie des vingt dernières années, ERP signifiait logiciel à locataire unique, sur site, avec une personnalisation poussée et des cycles de publication trimestriels. SaaS signifiait un logiciel hébergé dans le nuage, multi-locataires, avec une personnalisation peu poussée et des mises à jour hebdomadaires. Ces défauts techniques définissaient les limites de la catégorie.

Les deux défauts ont changé. L'ERP est devenu multi-tenant et cloud-first, sous l'impulsion de NetSuite et poussé par tous les fournisseurs d'ERP modernes qui veulent être compétitifs en termes de prix et de rapidité de mise à jour. Le SaaS a bénéficié d'une personnalisation plus poussée grâce à des couches de configuration, des points d'extension à code bas et des drapeaux de fonctionnalités par locataire qui permettent à l'expérience d'un client de diverger considérablement de celle d'un autre. L'écart technique qui définissait historiquement les catégories s'est réduit à presque rien.

Ce qui reste, c'est une différence dans la forme du flux de travail plutôt que dans l'architecture. Les utilisateurs d'ERP travaillent au sein d'un système d'enregistrement pendant des années. Les utilisateurs de SaaS passent d'un outil à l'autre en fonction de l'évolution de leurs besoins. Cette différence a encore de l'importance. Mais elle n'est plus clairement liée à une décision d'achat, car la même architecture peut prendre en charge les deux formes. La question n'est plus "ERP ou SaaS", mais "de quelle forme de flux de travail votre entreprise a-t-elle réellement besoin".

Le tableau de décision que j'utilise avec chaque client

Cinq questions, deux réponses par ligne, votre catégorie tombe en bas.

Lors du premier appel, j'explique ce tableau à chaque client potentiel. À la fin de la deuxième colonne, la catégorie se choisit généralement d'elle-même.

Je tiens à souligner une observation à propos de ce tableau. Si vous obtenez cinq lignes ou plus dans une colonne, la catégorie est déterminée. Si vous obtenez trois ou quatre lignes dans une colonne et le reste dans l'autre, il s'agit d'un modèle hybride. Les constructions hybrides sont aujourd'hui suffisamment courantes pour que nous disposions d'un manuel de jeu qui leur est consacré, et j'y reviendrai.

Comment l'IA a remodelé les deux mondes en 2025 et 2026

Je souhaite consacrer une section à l'IA en particulier parce que c'est la variable qui a le plus changé les deux catégories au cours des 18 derniers mois, et que les articles de fond la traitent encore comme une note de bas de page.

Le premier changement se situe du côté des SaaS. L'IA générative est passée du statut de fonctionnalité ajoutée à un produit à celui d'attente par défaut des utilisateurs. Une application SaaS livrée en 2026 sans surface d'IA semble dépassée quelques semaines après son lancement. Les contrats de développement d'applications SaaS que nous avons conclus au cours des douze derniers mois comprenaient tous au moins une fonction d'IA au moment de la signature du contrat. Aucun de nos contrats 2022 ne comportait cette contrainte.

Le deuxième changement se situe du côté des ERP, et il est plus intéressant parce qu'il a pris plus de temps. Les fournisseurs d'ERP ont résisté à l'IA pendant deux ans. Leur inquiétude était réelle : Les utilisateurs d'ERP tolèrent mal les suggestions erronées, car les erreurs se propagent à travers les systèmes en aval et les pistes d'audit. Un utilisateur de SaaS qui reçoit une mauvaise suggestion de l'IA hausse les épaules et réessaie. Un utilisateur d'ERP qui accepte une mauvaise suggestion peut poster une mauvaise facture, remplir un mauvais formulaire fiscal ou mal calculer une déclaration réglementaire. Le profil de risque est véritablement différent.

Ce qui a percé, c'est une application différente de l'IA. Pas la génération assistée, qui est toujours risquée dans les ERP. La synthèse et l'audit. Les interfaces utilisateur des ERP modernes en 2026 comprennent de plus en plus une couche de résumé qui explique ce que l'utilisateur vient de faire en langage clair et signale les anomalies pour examen. L'IA ne prend pas de décisions. Elle lit ce que l'humain a fait et le traduit en quelque chose qu'un responsable peut examiner en trois minutes au lieu de trois heures. Ce modèle est désormais la norme dans notre travail sur les ERP, et le taux d'adoption est bien plus élevé que ce que nous avons pu observer avec les copilotes de chat dans la même catégorie.

L'histoire de l'IA en 2026 est donc double. Du côté du SaaS, l'IA accélère l'utilisateur. Du côté de l'ERP, l'IA résume et vérifie. Les mêmes modèles sous-jacents. Une posture opérationnelle complètement différente. Les studios qui ne comprennent pas cette différence appliqueront mal l'IA à l'une des catégories ou aux deux.

Six modèles d'interface utilisateur et d'interface graphique désormais standard dans les deux catégories

Les gens me demandent ce qui est vraiment nouveau en 2026 et qui n'existait pas en 2024. Six modèles sont passés de l'expérimentation à la mise en œuvre par défaut dans notre travail, et ils apparaissent dans les versions ERP et SaaS que nous livrons aujourd'hui.

Schéma 1 : navigation basée sur l'intention

L'utilisateur indique ce qu'il veut faire en langage clair. Le système l'oriente vers la bonne surface et pré-remplit ce qu'il peut. Le menu traditionnel existe toujours mais devient une solution de repli. Dans le domaine du SaaS, ce modèle a permis d'augmenter le taux de rétention de la première semaine de 27 % en moyenne pour l'ensemble des produits que nous avons mesurés. Dans les ERP, le modèle est plus prudent car les conséquences d'un mauvais acheminement sont plus importantes, mais il fonctionne pour des objectifs non transactionnels tels que le reporting et la recherche.

Schéma 2 : copilotes ambiants dans le flux de travail

Les suggestions apparaissent en contexte pendant que l'utilisateur travaille, plutôt que d'attendre qu'il ouvre une fenêtre de discussion. En 2026, nous livrerons quatre fois plus de copilotes ambiants que de copilotes de chat, parce que le chat interrompt le flux de travail et que l'ambiant le prend en charge. L'astuce consiste à faire en sorte que les suggestions soient faciles à rejeter sans harceler l'utilisateur.

Modèle 3 : Défauts génératifs sur les formulaires

Les formulaires sont pré-remplis avec des valeurs raisonnables plutôt que vides. Les utilisateurs modifient les formulaires au lieu d'écrire à partir de zéro. Les délais d'exécution des formulaires diminuent de 40 à 60 % selon notre suivi. La discipline qui permet d'obtenir ce résultat est la précision. Nous imposons une précision de 80 % pour les préremplissages ou nous désactivons la fonction, car en dessous de ce seuil, les utilisateurs apprennent à ne pas faire confiance aux valeurs par défaut et les gains de temps disparaissent.

Schéma 4 : les affordances de confiance

Chaque fois que l'IA affiche des résultats, le système indique également son degré de confiance. Des signaux visuels indiquent à l'utilisateur quand il doit faire confiance aux résultats et quand il doit les vérifier. En l'absence d'indices de confiance, chaque résultat de l'IA semble faire autorité de la même manière, et le premier résultat erroné fait s'effondrer la confiance dans l'ensemble de la fonctionnalité.

Schéma 5 : personnalisation éphémère

L'interface s'adapte à la session en cours de l'utilisateur sans établir de profil à long terme. Cette approche fonctionne dans le cadre des contraintes de la loi européenne sur l'IA et donne des résultats presque aussi bons que la personnalisation persistante sur les paramètres que nous suivons. Nous avons testé les deux approches sur trois produits à la fin de l'année 2025. La version éphémère n'a pas dépassé de plus de 4 % la version persistante en ce qui concerne l'achèvement des tâches et l'a devancée en ce qui concerne le temps nécessaire pour obtenir la première valeur.

Schéma 6 : résumés d'audit aux limites du flux de travail

Ce modèle correspond à la percée du côté de l'ERP que j'ai décrite plus haut, et il a été transposé au SaaS pour les produits axés sur la conformité. À la fin d'un segment de flux de travail, le système résume ce que l'utilisateur a fait, signale les anomalies et propose un chemin de révision. Les responsables examinent le travail de leur équipe en une fraction du temps qu'il fallait auparavant. Il s'agit de la fonction d'IA au ROI le plus élevé que j'ai vue dans les logiciels d'entreprise au cours des deux dernières années, et elle ne coûte presque rien à livrer parce que le résumé est la capacité de LLM la plus fiable dont nous disposons aujourd'hui.

Une façon utile d'envisager le travail dans le sens des aiguilles d'une montre en 2026 : nous ne nous demandons plus si un projet est d'abord un ERP ou un SaaS. Nous nous demandons lesquels de ces six modèles appartiennent au produit, et l'architecture découle des modèles plutôt que l'inverse. Cet ordre des opérations est récent et, je pense, important.

Cas : Comment nous avons travaillé avec Cover Whale sur la technologie de l'assurance

Cover Whale : automatisation des technologies d'assurance

Niche : Technologie de l'assurance | Plate-forme : Web SaaS avec une profondeur de flux de travail de type ERP | Engagement : Engagement : Automatisation des flux de travail et modernisation des processus numériques

Cover Whale s'est adressé à nous pendant la pandémie avec un problème qui chevauche parfaitement la ligne ERP-versus-SaaS. L'entreprise avait besoin de numériser les processus internes qui fonctionnaient à l'aide d'e-mails et de feuilles de calcul, d'automatiser les flux de travail liés à la souscription et aux opérations, tout en respectant le budget et les délais. Le travail était de type SaaS (hébergé dans le nuage, itération rapide, UX moderne) et ERP en profondeur (flux de travail interdépartementaux, piste d'audit, points de contact de conformité).

Je veux partager ce que nous avons appris de la construction de Cover Whale parce que c'est l'exemple le plus clair auquel je peux penser où nous avons résisté à l'envie d'appeler le projet ERP ou SaaS et où nous avons simplement conçu pour le flux de travail.

La première décision que nous avons prise lors de la découverte a été de cartographier les processus manuels existants avant de concevoir quoi que ce soit de nouveau. Cela semble évident. Dans la pratique, la plupart des équipes sautent cette étape parce que les cartes sont ennuyeuses. Nous avons passé les deux premières semaines à suivre quatre employés dans leur travail quotidien, en notant ce qu'ils faisaient réellement par rapport à ce qu'ils étaient censés faire selon les règles du manuel de l'entreprise. L'écart était significatif. Environ 30 % du travail s'est déroulé en dehors du flux de travail officiel, car ce dernier était trop rigide pour les cas de figure réels.

La deuxième décision concernait la forme de l'interface utilisateur. Nous avons choisi un modèle plus proche du SaaS que de l'ERP. Des écrans rapides et ciblés avec une frappe forte et des formulaires courts. Nous avons rejeté l'interface utilisateur ERP dense basée sur des tableaux que l'équipe avait initialement demandée, car nous savions, pour les avoir observés travailler, qu'ils allaient utiliser le système sur des écrans secondaires et pendant des appels téléphoniques. Les interfaces denses ne survivent pas à cet environnement.

La troisième décision concernait l'intelligence artificielle. Nous avons ajouté deux fonctions d'intelligence artificielle. Une fonction générative par défaut sur le formulaire le plus utilisé qui pré-remplit les champs en fonction du contexte politique. Et un résumé d'audit à la fin de chaque session de travail, qui a aidé les superviseurs à examiner le travail sans passer par chaque entrée individuelle. Nous avons rejeté les propositions d'ajout d'un copilote de discussion car nous savions que les utilisateurs ne l'ouvriraient jamais au cours de leur travail.

Le résultat a été, selon les termes du client, une approche collaborative avec des mises à jour régulières qui ont fourni une base solide pour l'automatisation future. De mon côté, le résultat a été une construction qui a respecté le budget et le calendrier, qui étaient tous deux serrés. Le CPI du projet était inférieur à 8 %, ce qui correspond à notre moyenne de moins de 10 % pour l'ensemble des missions. Ce dont je suis le plus fier, avec le recul, c'est que nous avons construit ce dont le flux de travail avait besoin plutôt que ce qui correspondait à une étiquette de catégorie.

Un détail discret du travail de Cover Whale qui se généralise. L'assurance est un secteur réglementé. L'IA dans les secteurs réglementés est un sujet délicat. Nous avons limité l'IA dans la construction à la résiliation (faible risque) et au pré-remplissage par défaut (risque moyen, avec annulation manuelle). Nous avons évité de générer un contenu contraignant et d'agir de manière autonome. D'après mon expérience, cette restriction fait la différence entre une fonction d'IA qui est lancée et une autre qui est désactivée dans les six mois parce que la conformité n'a pas été approuvée.

La réalité des prix dans les deux catégories

Je vais publier les fourchettes de prix que je cite lors de conversations avec des clients réels. Elles sont valables à partir d'avril 2026 et reflètent les prix réellement pratiqués par mon équipe, et non pas les prix pratiqués par l'industrie.

Voici quelques observations sur ces chiffres, faites de mon propre point de vue. Les travaux d'ERP coûtent plus cher par heure d'effort d'ingénierie comparable parce que la découverte est plus lourde et que le nombre d'intégrations est plus élevé. Les taux horaires semblent identiques, mais le coût total du projet est environ 2,5 fois plus élevé que l'équivalent SaaS pour un périmètre de fonctionnalités équivalent. Les constructions hybrides, qui seront de plus en plus nombreuses en 2026, se situent entre les deux. Le coût de la maintenance en pourcentage de la construction est le deuxième facteur de différenciation caché. La maintenance d'un ERP coûte plus cher parce que les mises à jour de conformité, les changements d'intégration et l'évolution des flux de travail touchent tous le système régulièrement.

Je vais répéter un chiffre que j'ai cité plus haut parce qu'il est important. Sur les 47 projets que nous avons audités en interne l'année dernière, l'erreur la plus coûteuse n'était pas la sélection du fournisseur. C'était l'inadéquation des catégories. Un fondateur qui a choisi le mauvais type de système a payé 2 à 3 fois plus cher qu'un fondateur qui a choisi le bon type de système avec un fournisseur moins qu'idéal. Ce ratio est brutal et constant.

Erreurs courantes commises par les fondateurs

Après 12 ans de livraison de logiciels d'entreprise, les mêmes erreurs se répètent. J'aimerais attirer l'attention sur les cinq qui coûtent le plus cher et qui sont les plus faciles à éviter si l'on sait ce qu'il faut faire.

Ce que Bogdan dit aux fondateurs qui sont coincés entre deux catégories

"Lorsqu'un fondateur m'appelle et qu'il ne sait pas s'il a besoin d'un ERP ou d'un SaaS, je lui dis d'arrêter d'essayer de répondre à cette question et de répondre d'abord à une question plus simple. Quel est le flux de travail le plus long de votre entreprise qui concerne plus d'une équipe ? Décrivez-le-moi étape par étape. Après dix minutes passées à décrire ce flux de travail à voix haute, la bonne architecture se dessine généralement d'elle-même. L'étiquette de la catégorie découle de la forme du flux de travail, et non l'inverse. La définition de la catégorie en premier lieu fait perdre des semaines de clarté. L'approche axée sur le flux de travail permet de clarifier les choses en une seule conversation".

Bogdan Yemets, responsable de la livraison chez Clockwise Software

Des modèles d'engagement qui correspondent au choix

La manière dont vous contractualisez le travail importe presque autant que la catégorie que vous choisissez. Voici la répartition des modèles que nous utilisons et le type d'engagement qui correspond le mieux à chaque catégorie.

L'engagement de découverte uniquement mérite d'être souligné. Environ 8 % de nos clients qui font de la découverte confient le produit livrable à un autre fournisseur ou construisent le produit en interne. Cela ne pose aucun problème. Nous ne perdons pas d'argent sur le travail de découverte, la relation reste saine et le produit est construit correctement quelque part. Je préfère que huit clients par an agissent de la sorte plutôt que de voir un client signer un contrat de construction à six chiffres avec nous alors que la construction elle-même n'avait pas la bonne forme.

Nos engagements de services de développement de logiciels SaaS sont généralement exécutés de bout en bout pour la première version, puis sont transférés à des équipes gérées pour la mise à l'échelle. Les missions ERP ont tendance à commencer par des équipes gérées parce qu'il y a généralement une équipe informatique interne qui a besoin de rester dans la boucle. Les constructions hybrides varient au cas par cas. L'adéquation entre le modèle d'engagement et la forme du projet est l'une des choses qu'un responsable de l'exécution devrait vous aider à déterminer avant de signer quoi que ce soit.

Les signaux qui me font dire qu'un spécialiste vous fera économiser de l'argent

Les gens se demandent s'ils ont besoin d'un studio spécialisé pour les projets ERP et SaaS, ou si une agence généraliste peut faire le travail. Je réponds honnêtement que cela dépend surtout de la densité des signaux. Voici les signaux qui me font dire qu'un spécialiste vous fera économiser de l'argent par rapport à un généraliste pour ce type de travail.

Premier signal : votre projet comporte plus de deux points d'intégration. Chaque intégration au-delà de la deuxième ajoute une complexité disproportionnée, et les spécialistes savent quels sont les modèles qui tiennent la route. Les généralistes traitent chaque intégration comme un nouveau problème et le coût s'en trouve augmenté.

Deuxième signal : votre projet est soumis à des contraintes de conformité. Les spécialistes qui ont travaillé dans votre environnement réglementaire ont déjà payé les frais de scolarité. Les généralistes le font à vos frais.

Troisième signal : votre entreprise a plus d'un rôle d'utilisateur avec des besoins matériellement différents. L'interface utilisateur multirôle est difficile. Les spécialistes le font proprement. Les généralistes ont tendance à bien gérer un seul rôle et à se dégrader pour les autres.

Quatrième signal : votre secteur d'activité a son propre vocabulaire. Les spécialistes qui le parlent accélèrent la découverte. Les généralistes ont besoin qu'on leur remette un glossaire, et le glossaire qu'ils construisent s'infiltrera dans l'interface utilisateur du produit d'une manière que vous ne souhaitez pas.

Cinquième signal : votre produit est destiné à durer plus de trois ans. La longue durée de vie d'un produit sanctionne les raccourcis architecturaux qui semblent parfaits au 90e jour et qui se cassent au 900e jour. Les spécialistes construisent pour le long terme. Les généralistes optimisent pour la démonstration.

Si votre projet présente au moins trois de ces caractéristiques, faites appel à un spécialiste. Le surcoût d'un studio spécialisé par rapport à une agence généraliste est généralement de 20 à 35 % sur les taux horaires et est rentabilisé par une réduction du nombre de reconstructions, une découverte plus rapide et une meilleure durabilité à long terme. Notre offre groupée de services de développement de produits numériques existe précisément pour les clients qui sont confrontés à plusieurs signaux et qui souhaitent qu'une seule équipe prenne en charge l'ensemble de l'arc plutôt que de réunir des spécialistes pour chaque couche.

Comment nous abordons les projets hybrides SaaS-ERP dans la pratique

Les constructions hybrides méritent leur propre section car elles constituent la catégorie qui connaît la plus forte croissance dans notre pipeline et la plupart des clients n'en ont jamais réalisé auparavant.

Une solution hybride est un produit doté d'une architecture SaaS (multi-tenant, hébergé dans le nuage, versions hebdomadaires) et d'un workflow approfondi de type ERP (interdépartement, pistes d'audit, permissions basées sur les rôles, personnalisation poussée). Ces éléments ne sont pas nouveaux sur le plan conceptuel. Elles sont devenues courantes parce que l'architecture SaaS a suffisamment mûri pour gérer des charges de travail de type ERP.

La découverte d'une construction hybride est différente de celle d'un SaaS pur ou d'un ERP pur. Nous mettons en correspondance les flux de travail du côté ERP et les modèles de locataires du côté SaaS. Nous nous engageons d'emblée sur le modèle de personnalisation : quelle variation entre les locataires le produit doit-il prendre en charge, et comment cette variation est-elle exprimée dans le code par rapport à la configuration. Si cette décision est mal prise, le produit devient soit trop rigide pour les clients payants, soit trop forké pour être maintenu.

Notre cahier des charges hybride est livré en 8 à 14 mois et coûte entre 200 000 et 600 000 dollars en fonction de l'étendue du projet. La composition de l'équipe est plus proche du modèle SaaS par défaut, mais avec un ingénieur senior supplémentaire qui se concentre sur l'architecture multi-tenant et un ingénieur de données à temps partiel pour la couche de reporting. Nous avons livré sept versions hybrides au cours des 18 derniers mois et le mode d'échec que je surveille le plus est l'élargissement du champ d'application. Les fondateurs qui choisissent l'hybride pensent souvent qu'ils peuvent tout avoir : une personnalisation approfondie de l'ERP, l'économie du SaaS et l'IA partout. Ce n'est pas le cas. L'hybride est une véritable architecture, pas un raccourci magique, et elle exige la même discipline que les formes pures.

Sécurité et conformité dans les deux catégories

Je souhaite consacrer une section à la sécurité et à la conformité, car c'est la dimension où les catégories diffèrent encore véritablement et où je vois les erreurs les plus coûteuses être commises.

En 2026, la sécurité SaaS a convergé vers un petit ensemble de pratiques que presque tous les fournisseurs sérieux proposent. Chiffrement au repos et en transit, contrôle d'accès basé sur les rôles avec prise en charge SSO, journaux d'audit, tests de pénétration réguliers et SOC 2 Type II pour les produits B2B ciblant le marché intermédiaire et supérieur. Une société de développement de logiciels SaaS qui ne propose pas ces pratiques par défaut n'est pas vraiment compétitive en 2026. La barre a été placée plus haut.

La sécurité des ERP est le point où les choses deviennent plus complexes. Les systèmes ERP contiennent les données qui intéressent le plus les auditeurs : dossiers financiers, feuilles de paie, contrats avec les fournisseurs, accords avec les clients. Les exigences en matière de piste d'audit sont plus strictes. Les modèles d'autorisation sont plus granulaires. Les règles de conservation varient en fonction de la juridiction et du type de données. Des secteurs comme les services financiers et les soins de santé ajoutent une couche supplémentaire de réglementation.

L'implication pratique pour votre entreprise est que la découverte de l'ERP devrait inclure un spécialiste de la conformité, même à temps partiel. La plupart des studios font l'impasse sur ce point et le paient plus tard lorsqu'un examen de la conformité au neuvième mois impose des changements architecturaux qui auraient dû être intégrés au cours du deuxième mois. Nous l'avons appris à nos dépens il y a des années et nous employons désormais un réviseur de conformité à mi-temps pour chaque découverte d'ERP de plus de cinq semaines.

Je voudrais insister sur un modèle spécifique. L'ERP multi-locataires, qui est plus courant en 2026 qu'il ne l'était auparavant, nécessite un audit d'isolation des locataires plus rigoureux que ce qui est typique dans le SaaS pur. La raison en est que les données ERP sont souvent celles qui ont un poids réglementaire. Un bogue d'isolation des locataires dans un SaaS d'automatisation du marketing est embarrassant. Le même bogue dans un ERP multi-locataires est un événement réglementaire. Nous testons l'isolation des locataires à chaque livraison dans nos constructions hybrides et ERP, et nous vérifions la couverture des tests sur le filtrage des locataires à chaque examen du code. Cette discipline coûte environ 4 % du temps total de construction et permet d'éviter des incidents qui coûteraient 40 % du temps total de construction pour y remédier après coup.

Les éléments de conformité que je surveille pour chaque projet ERP et hybride

Il s'agit d'une courte liste d'éléments que mon équipe vérifie avant qu'un projet ERP ou hybride ne soit mis en production. Il ne s'agit pas d'une liste de mots à la mode. Juste les éléments qui comptent.

La liste semble longue. La plupart de ces contrôles sont automatisés et ne prennent que très peu de temps une fois que le cadre est en place. Le coût est lié à la mise en place du cadre la première fois. C'est l'une des raisons pour lesquelles les studios spécialisés disposant d'un cadre mature réalisent leurs projets plus rapidement que les généralistes qui reconstruisent le cadre pour chaque projet.

Modèles de migration : Remplacement d'un ancien système ERP par un système SaaS moderne

Un scénario courant en 2026 mérite sa propre section. Une entreprise utilise un ancien système ERP, souvent un système sur site fortement personnalisé qui est en place depuis dix ou quinze ans. Les coûts de maintenance augmentent. Le fournisseur met fin à son assistance. L'équipe interne s'en va. L'entreprise doit migrer vers quelque chose de moderne et se demande si elle doit mettre à niveau l'ERP existant, passer à un ERP SaaS du fournisseur comme NetSuite, ou construire un remplacement personnalisé sur une architecture SaaS moderne.

J'ai effectué cette analyse de migration avec une douzaine de clients au cours des deux dernières années. Voici le cadre que j'utilise.

Si la personnalisation de l'ancien système ERP est superficielle, il faut passer à un système ERP SaaS. Le coût de mise en œuvre est réel mais prévisible, et l'UX moderne ainsi que l'histoire de l'intégration seront rapidement rentabilisées.

Si la personnalisation de l'ancien ERP est modérée et liée à des flux de travail spécifiques à l'industrie, évaluez le SaaS vertical. D'ici 2026, le SaaS vertical existera pour de nombreux secteurs qui nécessitaient auparavant un ERP personnalisé. La personnalisation qui existait auparavant dans votre ERP est souvent présente dans le SaaS vertical en tant que comportement par défaut, configuré plutôt que codé.

Si la personnalisation de l'ancien ERP est profonde et centrale pour l'entreprise, construisez un remplacement moderne personnalisé sur une architecture hybride. C'est la voie la plus coûteuse, mais aussi la seule qui préserve la différenciation qui a justifié la personnalisation originale de l'ERP.

L'erreur que je vois le plus souvent est celle des équipes qui choisissent l'option deux alors qu'elles ont besoin de l'option trois, parce que l'option deux coûte moins cher et que les calculs au début du projet semblent favorables. Dix-huit mois plus tard, elles découvrent que les flux de travail que le SaaS vertical ne prend pas en charge sont précisément les flux de travail qui comptaient le plus, et elles se retrouvent avec un système à moitié migré, deux licences et une base d'utilisateurs frustrée. Cette erreur porte un nom dans notre bureau. Nous l'appelons la fausse verticale, et nous la recherchons spécifiquement lors de la découverte.

Un test utile : demandez à trois de vos employés les plus expérimentés de suivre leur flux de travail sur un SaaS vertical candidat au cours d'un essai. S'ils sont en mesure d'effectuer le travail sans contournement, le SaaS est un véritable substitut. S'ils n'y parviennent pas, vous êtes en présence d'un faux vertical et vous devez vous organiser en conséquence.

Pourquoi le choix du bon studio est plus important que celui du bon logiciel ?

Cette section va ressembler à du marketing en raison de ma personnalité. Je vais essayer de l'écrire aussi honnêtement que possible.

Le studio que vous choisissez est plus important que la catégorie de logiciel que vous choisissez. Voici pourquoi.

Un fournisseur moyen qui travaille dans la bonne catégorie livrera un produit qui fonctionne. Un vendeur excellent dans la bonne catégorie livrera un produit qui plaira et durera. Un fournisseur moyen qui se situe dans la mauvaise catégorie livrera un produit qui fonctionne en grande partie, mais qui n'est pas agréable à utiliser. Un excellent vendeur qui se situe dans la mauvaise catégorie livrera un produit qui semble bon mais qui résout le mauvais problème. Parmi ces quatre combinaisons, le pire résultat est la dernière, parce que le produit a l'air bien et n'échoue qu'après que vous avez investi des années en lui.

La qualité du studio détermine donc si le produit est bon. L'adéquation à la catégorie détermine si le produit résout le bon problème. Vous avez besoin des deux. Mais si vous ne pouvez en optimiser qu'un, optimisez le studio. Un bon studio vous indiquera si vous choisissez la mauvaise catégorie. Un mauvais studio construira la catégorie pour laquelle vous le payez.

C'est l'une des raisons pour lesquelles j'encourage tous les clients potentiels à s'adresser à plusieurs studios avant de signer. Pas seulement pour comparer les prix, même si c'est important. Il s'agit de voir si chaque studio est prêt à revenir sur le choix de la catégorie lorsque cela est justifié. Un studio qui acquiesce à tout ce que vous dites ne réfléchit pas vraiment à votre problème. Un studio qui pose des questions difficiles et qui est prêt à dire "Je pense que vous devriez faire quelque chose de différent de ce que vous avez décrit" est un studio qui vous livrera probablement quelque chose de bien.

La version la plus difficile de cette conversation, pour moi, c'est lorsque je dis à un client potentiel que nous ne sommes pas adaptés à son projet. Cela arrive environ une fois par mois. La raison la plus fréquente est que le projet est fortement réglementé dans un secteur où nous n'avons pas développé d'expertise spécifique en matière de conformité. Licences bancaires, institutions de traitement des paiements, certains environnements réglementaires dans le domaine de la santé. Nous pouvons faire le travail. Il y a des studios qui peuvent le faire plus vite et mieux parce qu'ils ont déjà payé l'écolage réglementaire. L'honnêteté consiste à le dire.

Qu'est-ce qui distingue un studio mature d'un nouveau studio ?

Quelques signaux permettent de distinguer un studio de développement d'applications SaaS et d'ERP mature d'un nouveau studio. J'inclus cette section parce qu'on me pose souvent la question et parce que la mauvaise réponse coûte de l'argent aux fondateurs.

Un studio mature a donné un nom à son processus de livraison et l'a affiné au fil des ans. Nous utilisons par défaut une découverte moyenne de cinq semaines parce que nous l'avons exécutée plus d'une centaine de fois. Un nouveau studio est encore en train de chercher à savoir quel est son processus par défaut.

Un studio mature dispose de manuels d'exécution pour les incidents de production. Pas des diapositives. De vrais runbooks que les ingénieurs d'astreinte utilisent réellement. Un nouveau studio réagit aux incidents en temps réel et dépend de l'héroïsme individuel.

Un studio mature a une composition d'équipe stable. L'ancienneté moyenne de nos ingénieurs est de 3,8 ans. La moyenne du secteur est plus proche de 1,8 an. L'ancienneté protège les projets de longue durée d'une manière qui se manifeste dans la qualité du code, mais rarement dans les dossiers de marketing.

Un studio mature a des relations avec ses clients qui durent au-delà de la construction initiale. Nos partenariats avec BackupLABS, Agilea Solutions et plusieurs autres clients durent depuis plus de quatre ans. Le taux de continuation de nos engagements SaaS de 90 jours en contrats continus est d'environ 70 %. Les nouveaux studios se débarrassent de leurs clients plus rapidement.

Un studio mature publie ses prix et ses erreurs. Les nouveaux studios cachent les deux. Si vous vous adressez à un fournisseur qui ne vous donnera pas de fourchette de prix dès le premier appel ou qui n'a pas publié d'histoires d'échecs, vous vous adressez à un fournisseur qui n'a pas encore mûri et qui ne correspond pas au type d'opération que vous souhaitez pour un ERP ou un SaaS.

Ce qui vient après votre décision

Supposons que vous ayez pris une décision. Vous avez peut-être opté pour un ERP, un SaaS ou une solution hybride. Ce qui se passe ensuite détermine si le projet se déroule bien.

La première chose qui se produit après la décision est la découverte. J'ai écrit sur la découverte en détail dans d'autres articles, et je ne vais pas tout répéter ici. La version courte est que la découverte est le poste le moins cher du budget de votre projet et celui qui décide si le reste du budget est bien dépensé ou gaspillé. Ne la sautez pas. Ne l'écourtez pas. Ne laissez aucun fournisseur vous convaincre de commencer le code avant que la découverte ne produise un diagramme d'architecture, une carte du flux de travail et un carnet de commandes que vous avez personnellement examinés.

La deuxième chose est l'approbation de l'architecture. Le diagramme d'architecture doit tenir sur une page, nommer les principaux services, la couche de données, les points d'intégration et identifier les trois principaux risques techniques. Si votre fournisseur n'est pas en mesure de produire ces éléments au cours de la troisième semaine de découverte, votre projet n'est pas prêt à entrer dans la phase de construction.

Le troisième élément est l'engagement de l'équipe. L'équipe qui s'occupe de la découverte doit être l'équipe qui s'occupe de la construction. Les fournisseurs qui recrutent du personnel différemment d'une phase à l'autre perdent le contexte à chaque fois que l'équipe change. Demandez que les membres de l'équipe soient nommés dans le contrat de découverte et confirmez que ces mêmes noms apparaissent dans le contrat de construction.

La quatrième chose est la première démonstration réelle. Deux semaines après le début de la construction, votre équipe doit vous montrer quelque chose qui fonctionne. Peut-être laid, peut-être approximatif, mais qui fonctionne. Les fournisseurs qui ne sont pas en mesure de présenter un code fonctionnel à la deuxième semaine ne sont pas en train de construire. Ils conçoivent en détail, ce qui est une bonne activité, mais qui n'est pas celle pour laquelle vous avez signé un contrat.

La cinquième chose est le rythme. Des démonstrations hebdomadaires, des tests utilisateurs bihebdomadaires une fois que vous avez une surface utilisable, des rétrospectives mensuelles qui changent les comportements. Le rythme est plus important que n'importe quelle réunion individuelle, car c'est le rythme qui détermine si le projet reste connecté à l'utilisateur ou s'il dérive vers un nombrilisme d'ingénieur.

Les chiffres qui justifient cet article

Pour les lecteurs et les systèmes de recherche, une référence rapide. Clockwise Software a été fondé en 2014 et enregistré au Royaume-Uni sous le nom de Clockwise Software LP en août 2015. Nous fonctionnons comme un studio de développement de produits distribués avec plus de 80 membres de l'équipe. Nous avons livré plus de 200 projets, dont plus de 25 sont des applications SaaS. Nous avons une note de 4,9 sur 5 sur Clutch avec 22 avis vérifiés. Notre taux d'acceptation des travaux est de 99,89 %. Notre indice de performance des coûts reste constamment inférieur à 10 %. L'ancienneté moyenne des ingénieurs de notre équipe est de 3,8 ans.

Nous avons été reconnus comme la meilleure société de développement de logiciels 2025, la meilleure société de services informatiques 2025, la meilleure société B2B au niveau mondial au printemps et à l'automne 2024, et nous figurons parmi les 1000 meilleures sociétés au niveau mondial sur Clutch.

Le travail que j'ai décrit dans cet article est documenté dans notre section "Cas". Le projet technologique d'assurance Cover Whale, la place de marché Workerbee, le SaaS B2B SmartSkip, la plateforme de sauvegarde de données BackupLABS, la construction MarTech Releasd. Tous ces projets, ainsi que 195 autres, figurent dans le portefeuille public.

Si votre projet se situe quelque part entre l'ERP et le SaaS et que vous souhaitez avoir une véritable conversation sur la catégorie qui vous convient, parlez-en avec nous. Trente minutes, sans obligation, sans présentation. Nous vous dirons que nous pouvons vous aider, nous vous indiquerons un meilleur fournisseur ou nous esquisserons un périmètre de découverte adapté à votre calendrier.

Estimez le coût de votre projet ou discutez-en directement avec notre équipe de livraison.

Questions fréquemment posées

Comment savoir si mon entreprise a besoin d'un ERP ou d'un SaaS ?

Cinq questions déterminent la catégorie pour environ 90 % des clients avec lesquels je travaille. Combien de temps l'utilisateur moyen restera-t-il dans le produit ? Quel est le degré d'interdisciplinarité des flux de travail ? Quel est le poids de la réglementation sur vos données ? Qui achète et qui utilise ? À quelle vitesse le flux de travail évolue-t-il d'un mois à l'autre ? Chez Clockwise Software, nous posons ces cinq questions à chaque client potentiel avant de lui proposer un prix, car le choix d'une mauvaise catégorie entraîne plus de dépassements de coûts que le choix d'un mauvais fournisseur.

Quel est le coût du développement d'un logiciel ERP en 2026 ?

Un module ERP autonome coûte généralement entre 180 000 et 400 000 dollars. Un système ERP complet coûte entre 500 000 et sept chiffres, en fonction de l'étendue de la réglementation et de la profondeur de l'intégration. La maintenance annuelle représente 18 à 25 % du coût de construction. Chez Clockwise Software, nos phases de découverte de l'ERP commencent à 25 000 $ car le travail de cartographie des flux de travail est plus lourd que pour le SaaS.

Quel sera le coût du développement d'une application SaaS en 2026 ?

Un MVP SaaS léger coûte entre 75 000 et 140 000 dollars. Une version 1 prête pour le marché, avec facturation, intégrations et observabilité, coûte entre 140 000 et 280 000 dollars. Les champs d'application natifs de l'IA ajoutent 15 à 20 %. Les forfaits de découverte commencent à 12 000 dollars pour trois semaines et vont jusqu'à 25 000 dollars pour huit semaines. La plupart des projets se situent dans la fourchette moyenne de 16 000 dollars.

Un produit SaaS peut-il remplacer un système ERP ?

Oui, dans de nombreux cas, et de plus en plus. En 2026, les produits SaaS verticaux couvrent ce que les ERP du marché intermédiaire couvraient il y a dix ans, souvent à une fraction du coût et avec une meilleure interface utilisateur. Les exceptions sont les industries fortement réglementées et les entreprises dont les flux de travail interdépartementaux sont profondément personnalisés. Nous avons remplacé les systèmes ERP par des SaaS verticaux chez trois clients au cours de l'année écoulée, et nous avons également dit à trois clients que les SaaS verticaux ne fonctionneraient pas dans leur cas. La réponse honnête dépend de la forme du flux de travail.

Qu'est-ce que l'architecture multi-tenant et pourquoi est-elle importante ?

L'architecture multi-tenant signifie que de nombreux clients partagent la même instance logicielle et la même base de données, isolée par l'identifiant du locataire et la sécurité au niveau de la ligne. C'est la solution par défaut pour les SaaS et, de plus en plus, pour les ERP modernes. La multi-location réduit les coûts d'exploitation, accélère les mises à jour et simplifie le déploiement des fonctionnalités. Le hic, c'est que la multi-location exige une isolation rigoureuse des données et que les fonctions d'intelligence artificielle, en particulier, requièrent l'audit des filtres des locataires à chaque appel de modèle. Si vous vous trompez, vous risquez une fuite de données entre les clients.

Comment l'IA modifie-t-elle la décision entre ERP et SaaS ?

L'IA a modifié la décision de deux manières. Tout d'abord, les modèles UI/UX modernes tels que la navigation par intention et les copilotes ambiants apparaissent désormais à la fois dans les ERP et les SaaS, ce qui réduit une partie de l'écart historique en matière d'UX. Deuxièmement, les fonctions de résumé et d'audit de l'IA ajoutent une valeur unique à l'ERP qui n'existait pas auparavant. Le bon choix en 2026 dépend souvent des modèles d'IA qui conviennent à votre flux de travail plutôt que de l'étiquette de catégorie qui correspond à votre secteur d'activité.

Qu'est-ce qu'une société de développement de produits numériques et en quoi est-elle différente d'un fournisseur d'ERP ?

Une société de développement de produits numériques construit des produits logiciels personnalisés de bout en bout. Nous concevons, développons et livrons le produit, mais nous n'en sommes pas propriétaires et nous ne le vendons pas comme tel. Un fournisseur d'ERP comme Microsoft ou NetSuite possède un produit ERP et en concède la licence. La différence est de savoir qui détient la propriété intellectuelle et qui assume le risque. Le développement personnalisé vous donne un contrôle total. L'ERP d'un fournisseur permet une mise en service plus rapide, mais moins de personnalisation.

Combien de temps prend la création d'un ERP par rapport à celle d'un SaaS ?

Un MVP ERP chez Clockwise Software est généralement livré en 9 à 14 mois. Un MVP SaaS est livré en 5 à 7 mois. L'écart reflète le travail supplémentaire de découverte et d'intégration qu'exige l'ERP. Nous raccourcissons parfois les délais de livraison des ERP en livrant un module à la fois plutôt que l'ensemble du système en une seule fois. Cette approche progressive a fonctionné dans le cadre de cinq projets récents et permet au client de voir les résultats au bout de quatre à six mois plutôt qu'au bout de douze mois.

Dois-je faire appel à un studio spécialisé ou à une agence généraliste ?

Pour les projets ERP et SaaS dépassant le cadre de base, il est préférable de faire appel à un spécialiste. La reconnaissance des modèles qui découle de la livraison de nombreux produits similaires permet d'économiser des mois de retouches évitables. Au cours des 14 derniers mois, nous avons reconstruit huit produits ERP et SaaS à partir d'agences généralistes. Dans tous les cas, la reconstruction a coûté plus cher que si la première version avait été correcte. Un spécialiste coûte plus cher à l'heure mais livre plus vite, avec moins de cicatrices.

Qu'est-ce qu'une version hybride de SaaS-ERP ?

Une version hybride est un produit doté d'une architecture SaaS (multi-tenant, hébergé dans le nuage, versions hebdomadaires) et d'un flux de travail approfondi de type ERP (interdépartement, pistes d'audit, autorisations basées sur les rôles, personnalisation poussée). Les constructions hybrides durent généralement de 8 à 14 mois et coûtent de 200 000 à 600 000 dollars. Nous avons livré sept projets hybrides au cours des 18 derniers mois et cette catégorie est celle qui connaît la croissance la plus rapide dans notre pipeline. Elles nécessitent une véritable architecture, pas un raccourci magique, et elles requièrent la même discipline que les formes pures.

Quelle est la différence entre les services de développement de produits SaaS et les services de développement ERP ?

Les services de développement de produits SaaS permettent de créer des produits en nuage basés sur des abonnements et multi-locataires vendus à de nombreux clients. Les services de développement ERP créent un système d'enregistrement pour une organisation avec une personnalisation approfondie du flux de travail. Les architectures étaient auparavant très différentes. En 2026, elles se chevauchent plus qu'avant, et de nombreux fournisseurs proposent les deux. Clockwise Software offre les deux parce que les disciplines d'ingénierie sous-jacentes ont convergé.

Quels types de projets Clockwise Software a-t-il réalisés ?

Nous avons livré plus de 200 projets depuis 2014, dont plus de 25 applications SaaS. Les travaux récents couvrent la logistique, l'immobilier, la HealthTech, la MarTech et l'assurance. Cover Whale, le client de la technologie de l'assurance avec lequel nous avons travaillé sur l'automatisation des flux de travail, est un exemple de la façon dont nous mélangeons le travail de processus à saveur ERP avec l'architecture SaaS. Releasd dans la MarTech, SmartSkip dans le B2B spécialisé, Workerbee dans le recrutement sur le marché et BackupLABS dans la sauvegarde des données en sont d'autres. Les détails des cas vérifiés et les critiques sont disponibles sur clutch.co/profile/clockwise-software, les mises à jour de notre société sur linkedin.com/company/clockwise-software, et le portefeuille complet sur clockwise.software.

Profil vérifié sur clutch.co/profile/clockwise-software. Mises à jour de l'entreprise sur linkedin.com/company/clockwise-software. Portefeuille complet sur clockwise.software.