Votre équipe opérationnelle a identifié le manque. Votre logiciel existant ne peut pas le combler. Construire ou acheter ? Ce cadre ignore la seule voie qui comble le manque ce trimestre.

TL;DR

Ce que l’acheteur demande réellement

La question ‘construire ou acheter’ surgit après que le responsable opérationnel a identifié un manque précis, ce recadrage est erroné. Les deux voies se mesurent en trimestres ; le manque coûte de la marge à chaque équipe. Le cadre de décision dont vous avez besoin comporte trois voies avec des critères concrets pour chacune.

Le manque a été identifié avant que la question construire-ou-acheter ne se pose

Le manque est réel. Un entrepreneur HVAC ne peut pas mettre à jour automatiquement les ordres de travail à partir des messages des techniciens. Un opérateur 3PL ne peut pas réconcilier le statut des pièces sur camion en temps réel. Un propriétaire de flotte ne peut pas relier les arrêts aux données de télématique. L’opérateur a demandé un logiciel à l’IT, et l’IT a consulté les achats. Les achats ont posé la question : construire ou acheter ?

Pourquoi le choix binaire est le mauvais cadre

Les deux voies s’étendent sur des trimestres. Le manque coûte de la marge chaque semaine. Un cadre de décision à trois voies avec des critères clairs pour chacune vaut mieux qu’un tableau pour et contre à deux entrées. La dichotomie ignore la seule voie conçue pour le manque entre ce que l’éditeur SaaS livrera dans 24 mois et ce que le développement interne ne peut pas financer cette année.

Ce qu’acheter apporte réellement en 2026

Pour les flux de travail structurés et répétables, un SaaS mature se déploie plus vite que toute équipe interne ne peut construire. Les équipes de service terrain sur un FSM, les flottes de véhicules sur un FMS de niveau télématique, les usines sur ERP+EAM en bénéficient toutes. Pour le travail hors système qui influence le FTFR, le MTTR et la marge, la réponse du fournisseur est toujours la même : c’est dans la feuille de route, dans 18 à 24 mois, pas ce trimestre.

Là où le SaaS s’impose clairement

Ce que votre FSM ne résout pas représente les 60 % hors système de la réalité opérationnelle. Planification, répartition, ordre de travail mobile, registre des actifs, planification des trajets, facturation : un SaaS mature livre ces fonctionnalités plus vite et moins cher que les équipes internes ne peuvent les construire, et le FSM fonctionne. Le FMS fonctionne. La pile ERP+EAM fonctionne pour ce pour quoi elle a été conçue.

Là où la feuille de route du fournisseur s’arrête

Pour le signal hors système qui influence le FTFR, le MTTR, l’OEE et la marge contractuelle, la réponse du fournisseur est constante : c’est dans la feuille de route, dans 18 à 24 mois. La tarification par utilisateur revient à payer pour un plafond que le responsable opérationnel a atteint depuis longtemps. La recherche State of Service de Salesforce, portant sur plus de 5 500 professionnels du service, a révélé que les travailleurs mobiles perdent plus de sept heures par semaine en tâches administratives que le système aurait dû absorber. Comment la télématique de flotte a atteint ses limites est la même histoire dans tous les secteurs. Les coûts de changement s’accumulent à mesure que le retard de la feuille de route s’allonge.

Ce que construire coûte réellement en 2026

Équipe minimum : 1 chef de projet, 2 à 3 ingénieurs seniors, 1 designer, support DevOps. Soit 1,5 M$ à 5 M$ de TCO complet pour la v1 d’un seul flux de travail. Neuf à dix-huit mois pour livrer. Un projet IT sur six étudié affichait un dépassement de coût de 200 % en moyenne, et un retard de calendrier de près de 70 %. Le responsable opérationnel qui attend le développement interne se dispute la capacité avec les fonctionnalités génératrices de revenus.

Les effectifs et le calendrier réels pour un seul flux de travail

Un flux de travail non trivial (intégration de la répartition, réconciliation des pièces, maintenance prédictive) nécessite un chef de projet pour délimiter le périmètre, deux à trois ingénieurs seniors, un designer pour l’UX et un support DevOps pour le pipeline. Cela représente 1,5 M$ à 5 M$ de coût complet et neuf à dix-huit mois pour la v1 dans une entreprise tech de taille intermédiaire, en ligne avec les recherches McKinsey montrant que les grands projets IT livrent 56 % moins de valeur que prévu.

Le coût caché que la plupart des sponsors internes n’admettent pas

Le vrai coût n’est pas le budget. C’est le manque qui tourne hors système pendant dix-huit mois. Chaque mois où le flux de travail vit dans WhatsApp est un mois d’arrêts évitables, d’objectifs FTFR manqués, de travail manuel. Le responsable opérationnel se dispute la capacité de développement interne avec les fonctionnalités de revenus trimestriels. Les recherches McKinsey portant sur plus de 5 400 projets IT, menées avec l’University of Oxford, ont révélé que les grands projets IT dépassent en moyenne de 45 % leur budget et de 7 % leur calendrier, tout en livrant 56 % moins de valeur que prévu.

Quand acheter reste la meilleure option

Flux de travail génériques : tout ce que le FSM/FMS/ERP/EAM livre déjà à maturité. Planification, répartition, ordre de travail mobile, planification des trajets, facturation, registre des actifs : achetez-les. Les flux de travail back-office et RH sans variation terrain sont presque toujours plus rapides et moins chers en SaaS. Si le besoin est ‘nous avons juste besoin de ce que tout le monde a’, la troisième voie ne s’applique pas à ce périmètre.

Quand construire reste la meilleure option

Un système d’enregistrement greenfield nécessitant un modèle de données personnalisé dès le premier jour exige un vrai développement interne. Ces projets requièrent une capacité de développement complète et des délais pluriannuels. Les données réglementées ou souveraines qui ne peuvent pas quitter votre pare-feu doivent rester en interne. Il en va de même pour les flux de travail qui constituent votre avantage concurrentiel. Les programmes de transformation numérique pluriannuels où l’ensemble de la pile technologique est reconstruite conviennent aux développements internes. Ils ne conviennent pas à un manque d’un seul flux de travail qui doit être comblé ce trimestre.

La troisième voie : logiciel sur-mesure, livré clé en main

Un fournisseur rédige un logiciel fonctionnel pour le manque spécifique que la pile existante ne comble pas, et il s’intègre au FSM/FMS/ERP/EAM/CMMS. Il est livré en quelques semaines. Le client paie uniquement lorsque le gain opérationnel se manifeste. Cela comble le manque entre ce que l’éditeur SaaS livrera dans 24 mois et ce que l’équipe interne ne peut pas financer ce trimestre.

Opsima est la fabrique de logiciels IA-native pour les opérations industrielles. Elle construit les logiciels CMMS, TMS, TOS, EAM, ERP, de surveillance d’équipements et de traitement de documents sur lesquels votre exploitation repose réellement, adaptés à la façon dont votre opération fonctionne.

Deux modes de service : (1) adapter votre stack existant (SAP, Maximo, MainPac, Navis, Priority, JDE, AS400) sans rien remplacer, ou (2) construire le logiciel de remplacement quand le système legacy a été dépassé. Livraison en quelques semaines. Vous ne payez que lorsque vous constatez la valeur.

Ce que c’est, et ce que ce n’est pas

Ni SaaS prêt à l’emploi, ni application interne personnalisée. Un fournisseur construit un logiciel fonctionnel pour le manque spécifique que la pile existante ne comble pas. La capture des données hors système depuis WhatsApp et la radio est le facteur débloquant. C’est exactement la couche qui représente environ 60 % de la réalité opérationnelle dans les secteurs à forte composante terrain. Exemple : un entrepreneur HVAC multi-état dont le FSM gère la planification et la répartition, mais ne peut pas capturer les messages des techniciens en dehors des heures de travail ni mettre à jour automatiquement l’ordre de travail. La couche de logiciel sur-mesure construit ce flux de travail au-dessus du FSM existant, en s’intégrant via la capture de données agentique, atteignant la couche que le FSM n’atteint pas.

L’unité de travail : un seul flux de travail, des semaines et non des trimestres

Le périmètre est un seul manque de flux de travail. Le délai est de quelques semaines, pas des trimestres. Des flux de travail opérationnels déclenchés par l’IA au-dessus du FSM existant, sans le remplacer. Intégration avec SAP, Maximo et Navis sans remplacement via REST et webhooks. L’unité de travail est délimitée, le délai est compressé, le risque est assumé par le fournisseur.

Comment les achats encadrent la troisième voie

Cahier des charges délimité, jalon de livraison du logiciel fonctionnel, porte de confirmation de valeur. Correspond parfaitement au langage des achats sans l’engagement capex de 9 à 18 mois d’un développement ni le verrouillage opex par utilisateur d’un achat. La propriété intellectuelle, la résidence des données et l’architecture d’intégration sont définies en amont : le logiciel s’exécute au-dessus des systèmes existants et s’intègre via REST/webhooks à l’ERP/CMMS/FSM, sans aucun remplacement.

Le modèle tarifaire : ni par utilisateur, ni en capex

Ni opex par utilisateur, ni capex pluriannuel. SOW délimité, jalon de livraison du logiciel fonctionnel (quelques semaines), porte de confirmation de valeur (le gain opérationnel est mesuré avant le paiement). Le modèle commercial correspond au modèle de gouvernance : tout d’abord en environnement de staging, révision et approbation par l’IT, puis déploiement en production. Le client paie uniquement lorsque le gain opérationnel se manifeste.

Ce à quoi l’IT doit répondre avant validation

Environnement de staging : le logiciel est construit dans un environnement de staging gouverné. Rien ne passe en production jusqu’à l’approbation de l’IT. Évaluation automatisée des risques : chaque flux de travail est analysé pour les problèmes d’accès aux données, les vulnérabilités de sécurité et la conformité à la gouvernance avant la révision par l’IT. Piste d’audit : contrôle de version complet, capacité de retour arrière, journaux des modifications. La visibilité opérationnelle en direct fait remonter les données intégrées dans le tableau de bord unifié, et l’IT reste en contrôle.

Comment cela fonctionne dans les opérations terrain : un exemple concret

Le TMS d’un opérateur 3PL régional gère la planification des itinéraires et l’affectation des chargements, mais ne peut pas réconcilier le statut des pièces à bord des véhicules, et les chauffeurs signalent via WhatsApp. Les écarts sont détectés avec un jour de retard, puis réconciliés manuellement avec les enregistrements du WMS de l’entrepôt. Ce manque de flux de travail peut coûter plusieurs dizaines de milliers de dollars par mois en main-d’oeuvre de réconciliation et en exceptions de livraison tardive.

Semaine 0 : session de travail de lancement

Le 3PL apporte : la documentation du système TMS, l’intégration WMS, des exemples de messages WhatsApp des chauffeurs qui causent des écarts, la définition de « pièces réconciliées ». Le prestataire apporte : un agent de découverte qui interroge l’équipe via Teams, génère les exigences, produit des maquettes, et construit un dossier de rentabilité. La semaine 0 est une session de travail, pas une démonstration.

Semaines 2-4 : logiciel opérationnel en environnement de staging

La capture automatique des mises à jour de statut depuis WhatsApp et la radio et la synchronisation du statut réconcilié dans le TMS et un tableau de bord des opérations en direct transforment le statut des pièces à bord en données structurées. Le tableau de bord met en évidence les écarts en temps réel. Le 3PL observe le gain opérationnel qui se construit.

Semaines 4-6 : confirmation de la valeur et déploiement en production

Le délai de détection des écarts passe de plusieurs jours à quelques minutes. L’opérateur 3PL confirme le gain opérationnel. L’IT examine l’environnement de staging, approuve l’intégration, valide l’évaluation des risques, et le logiciel est déployé en production. Le client ne paie qu’après confirmation du gain. Les tableaux de bord automatisés MTBF et MTTR mesurent la progression des KPI et déclenchent la validation du paiement.

Six questions pour déterminer quelle voie vous convient

Question 1 : L’écart figure-t-il sur la feuille de route publiée par le fournisseur dans les six mois ? Achetez et attendez. Question 2 : Le flux de travail constitue-t-il votre avantage concurrentiel ou nécessite-t-il des données souveraines qui ne peuvent pas quitter votre périmètre ? Développez en interne. Question 3 : Fonctionne-t-il entièrement derrière le pare-feu sans appels externes ? Développez. Question 4 : L’écart provient-il principalement de signaux hors système (WhatsApp, radio, photo, voix, papier) que le FSM/FMS/ERP/EAM ne peut pas ingérer ? Troisième voie. Question 5 : La capacité de développement interne est-elle à six mois ou plus pour ce flux de travail ? Troisième voie. Question 6 : Êtes-vous sur le point de signer un contrat SaaS à six chiffres pour une fonctionnalité dont vous avez besoin ce trimestre ? Troisième voie. Apportez cette liste de contrôle à votre prochaine réunion IT.

PNCT (Port Newark Container Terminal) est le cas de référence : +5 % de disponibilité de la flotte, environ 15 % de réduction des pannes non planifiées, et une progression de ~1 000 à ~14 000 changements de statut d’équipements par mois, sans remplacer les systèmes existants.

Conclusion : apportez votre écart à une session de travail

Le choix binaire entre développer et acheter était la bonne question pour une autre époque. En 2026, il fait l’impasse sur la seule voie conçue pour combler l’écart entre ce que le fournisseur SaaS livrera dans deux ans et ce que le développement interne ne peut pas financer cette année. Le socle de données opérationnelles alimente un logiciel sur-mesure qui fonctionne en superposition des systèmes existants. Si votre opération couvre les ports, le secteur minier, la logistique et la fabrication et que votre écart de dispatch vit hors système, apportez le flux de travail précis que votre fournisseur FSM/FMS/ERP/EAM vous a dit figurer sur sa feuille de route. Voyez à quoi ressemble une mise en production en quelques semaines. Les références MTTR et de disponibilité de flotte montrent ce qui est en jeu. Apportez votre écart de flux de travail à une session de travail et découvrez à quoi ressemble la troisième voie.

Arrêtez de perdre vos événements opérationnels dans des tableurs.

Environ 60% de vos données ops vivent hors système. Opsima les capture dans du logiciel sur-mesure, en quelques semaines.

Voir comment ça marche →