Startups de suivi : oui à la vitesse, non au risque d'exploitation

27.07.2026

7 min de lecture

Les startups spécialisées en visibilité livrent en quelques semaines ce que les plateformes des grands groupes ne déploient parfois qu’au rythme des trimestres. Pour les DSI et les CDO, après la démo, ce qui compte n’est pas tant l’interface que la capacité d’intégration, l’export des données et la continuité de service en cas de rachat ou de faillite du fournisseur. Lorsqu’on considère la visibilité comme une fonction opérationnelle, on évalue les startups comme des fournisseurs de logiciels exposés à un risque de sortie. L’interface de démo passe alors au second plan.

Les points clés en bref

Commencez par un cas d’usage précis. La visibilité par startup offre un gain de temps pour combler des lacunes mesurables dans le suivi des conteneurs, des actifs et des exceptions, lorsque le module est intégré comme un satellite aux côtés du TMS et de l’ERP.
Due diligence avant l’UX. Les DSI vérifient les rôles et droits, le chiffrement, les certifications CAIQ et C5, les API versionnées ainsi que la trésorerie, la concentration des investisseurs et les références opérationnelles avec de vraies interfaces.
L’intégration crée la valeur. Les événements nécessitent un mappage canonique selon GS1 EPCIS, des données de référence propres et un modèle opérationnel pour la gestion des incidents, les modifications de schémas et la surveillance des pipelines, au-delà de l’interface de la startup.
Préparez la sortie avant le pilote. Un accord de séquestre avec des instructions de build, des clauses de changement de contrôle, des délais de migration et des exports lisibles par machine selon le Data Act de l’UE garantissent la continuité et la portabilité des données en cas de vente ou de défaillance.

Contenu associéEngagement dans l’IA et le cloud : le rythme des Capex devient inconfortable / VMware sous Broadcom : le plan de sortie comme levier

Quand les solutions des startups sont pertinentes

Les solutions des startups s’imposent là où un cas d’usage précis génère de la valeur plus rapidement qu’un module de plateforme large. Les lacunes typiques concernent le suivi des conteneurs et des actifs, la gestion des exceptions dans les chaînes multimodales ou les données IoT qui n’arrivent que partiellement dans le Transportation Management System (TMS) existant – le logiciel dédié à la planification et à l’exécution des transports. L’avantage se concrétise lorsque la lacune est mesurable et que le service métier maîtrise déjà le processus.

Gartner classe le marché des plateformes de visibilité des transports en temps réel (RTTVP) comme des solutions fournissant la localisation et le statut en temps réel des commandes et des envois, tout en s’interfaçant avec le TMS et l’ERP. GS1 EPCIS, la norme d’événements pour la visibilité de la supply chain, structure ces événements selon les critères « quoi, quand, où, pourquoi et comment ». Les critères de priorisation restent spécifiques à chaque entreprise : les DSI pondèrent les lacunes process mesurables, l’effort d’intégration et la proximité avec la facturation ou le pilotage des SLA.

Les startups sont en revanche moins adaptées pour remplacer discrètement les processus centraux de l’ERP et du TMS. Dès que le suivi s’intègre à la facturation, au pilotage des SLA ou à la conformité, les coûts d’intégration et de défaillance augmentent. La stabilité l’emporte alors sur la rapidité de la démo.

L’utilisation est judicieuse lorsque le DSI intègre délibérément le module de la startup comme un satellite. Cela implique une maîtrise limitée des données au sein de sa propre stack, des interfaces claires et un modèle opérationnel prédéfini. Sans cette intégration, la visibilité reste une solution isolée, coûteuse à remplacer.

La Due Diligence : sécurité, feuille de route et signaux de financement

La Due Diligence commence par la sécurité et les identités, et non par la vue cartographique. Il est question de concepts de rôles et de droits, de chiffrement en transit et au repos, de journalisation, de séparation des données des mandants ainsi que de preuves de tests de pénétration et de gestion des incidents. Pour les fournisseurs IoT, s’ajoutent l’identité des appareils, les chemins de mise à jour et la gestion des points de terminaison compromis.

Les cadres de référence établis servent de grille d’évaluation. Le questionnaire d’évaluation des initiatives de consensus (CAIQ) de la Cloud Security Alliance documente les contrôles de sécurité des fournisseurs IaaS, PaaS et SaaS selon la matrice des contrôles cloud et s’intègre au niveau 1 du registre STAR. La norme ISO/IEC 27001:2022 régit les relations avec les fournisseurs dans les contrôles de l’annexe A, sections 5.19 à 5.23, incluant l’utilisation du cloud et la surveillance des services fournisseurs. Le catalogue des critères de conformité au cloud computing du BSI (C5:2026) précise les exigences minimales pour un cloud sécurisé : 168 critères vérifiables répartis en 17 domaines, succédant au C5:2020 qui en comptait 121. Les lignes directrices de l’ENISA sur la sécurité IoT complètent ces aspects avec l’identité des appareils, les chemins de mise à jour sécurisés et la chaîne d’approvisionnement sur l’ensemble du cycle de vie.

La feuille de route doit s’articuler avec l’architecture propre de l’entreprise et ne pas se limiter à des slides destinées aux investisseurs. Les DSI vérifient si les API sont versionnées, si les modifications majeures sont annoncées et si les modèles de données restent stables. Une promesse fonctionnelle sans discipline de release contraignante ne constitue pas un objet de planification pour l’exploitation.

Les signaux de financement sont des signaux de risque opérationnel. La durée de fonctionnement restante, la concentration des investisseurs, la dépendance à un client majeur et les rumeurs de vente doivent figurer dans le catalogue des risques de la DSI. Les actualités de levées de fonds attestent de l’accès au capital. Les DSI n’en déduisent pas pour autant la maturité opérationnelle. Le NIST SP 800-161 Rev. 1 (Cybersecurity Supply Chain Risk Management) exige d’évaluer et de surveiller les fournisseurs de manière critique tout au long du cycle de vie, y compris leurs dépendances organisationnelles et financières. Les informations publiques sur la propriété et le financement s’intègrent à cette évaluation. Il n’existe pas de score sectoriel contraignant pour l’évaluation des risques des fournisseurs dans le domaine des SaaS de visibilité ; chaque entreprise définit ses propres seuils en interne.

Les références doivent refléter le même niveau d’intégration dont l’exploitation propre a besoin. Une démonstration réussie auprès d’une PME sans connectivité ERP en dit peu sur un fonctionnement en groupe avec TMS, données de base et rôles issus d’Active Directory. Il est nécessaire de disposer de références opérationnelles incluant des interfaces, des temps de support et une gestion réelle des exceptions.

Chemin d’intégration dans l’ERP et le TMS

La visibilité ne génère de valeur que lorsque les événements parviennent à la planification, à l’exécution et au pilotage. Le chemin d’intégration passe typiquement par la télémétrie et les événements de statut via une couche d’intégration vers le TMS et l’ERP. L’absence de modèle d’événements canonique entraîne des vérités doubles entre le portail du startup et le système central.

Le standard GS1 EPCIS 2.0 sert de référence : il décrit des événements de traçabilité interopérables et prend en charge JSON, REST et des motifs OpenAPI en plus du XML. Cela permet de partager les événements de statut, de localisation et de responsabilité entre partenaires et systèmes. Les architectures de référence, comme celle de la chaîne logistique de Microsoft Fabric, montrent le parcours des flux ERP et logistiques vers une couche de traitement commune via des flux d’événements. Une visibilité sans mapping canonique reste un tableau de bord parallèle.

Les données de base déterminent la qualité de la traçabilité. Les conteneurs, les envois, les commandes, les partenaires et les emplacements doivent être correctement mappés, sans quoi les alertes restent inutilisables en opérationnel. Les DSI doivent définir les responsabilités de mapping et de gestion des erreurs avant la mise en production, y compris la propriété en cas de messages de statut contradictoires.

Sur le plan technique, une couche API étroite et versionnée, avec des règles claires de retry, d’idempotence et de reprocessing, s’avère efficace. Les événements push pour les exceptions et les pull pour les rattrapages réduisent les vols en aveugle dans le quotidien. Le monitoring doit observer la pipeline elle-même, et non seulement l’interface utilisateur du startup.

Sur le plan organisationnel, ce chemin nécessite un modèle opérationnel : qui prend en charge les incidents, qui entretient les mappings, qui décide en cas de modifications de schéma ? Sans ces rôles, l’intégration reste un artefact de projet. Avec eux, la visibilité devient partie intégrante de la chaîne logistique et non un tableau de bord parallèle.

Éléments contractuels : séquestre, sortie et portabilité des données

Les contrats avec des fournisseurs de logiciels critiques garantissent la continuité d’activité au-delà de la phase de démonstration. Le séquestre du code source ou des artefacts de déploiement ne prend effet qu’avec des instructions de build et d’exploitation documentées, ainsi que des cas de déclenchement définis. Sans exécution technique, le séquestre reste symbolique.

Les motifs typiques de restitution, tels que décrits dans les guides sur le séquestre et les pratiques des prestataires, incluent l’insolvabilité, l’arrêt du support, la suspension temporaire ou définitive de l’activité commerciale, ainsi que le non-respect durable des obligations de maintenance en cours. L’étendue du dépôt doit couvrir le code source, les artefacts de déploiement, les dépendances et la documentation de build. Les obligations de vérification – allant du contrôle structurel à l’essai de compilation et d’exploitation fonctionnelle – déterminent si le dépôt est exploitable en cas de besoin.

Les clauses de sortie régissent la résiliation, la migration et les délais de transition en mois, adaptés à l’écosystème informatique. Il est essentiel de prévoir des obligations d’assistance pour l’export des données, les tarifs d’aide à la migration, ainsi que la gestion des sous-traitants après un changement de fournisseur ou une acquisition. Un changement de contrôle doit déclencher un droit d’audit et, le cas échéant, un droit de résiliation spéciale.

La portabilité des données est la devise forte dans un contexte de sortie SaaS. Depuis le 12 septembre 2025, l’EU Data Act (règlement (UE) 2023/2854) s’applique. Le chapitre VI impose aux prestataires de services de traitement de données – y compris les solutions SaaS – de faciliter la transition : les données et actifs numériques exportables doivent être portables, sans obstacles techniques ou contractuels inutiles. Les contrats doivent stipuler les formats, l’exhaustivité, la fréquence et les essais d’export, y compris les événements historiques et la configuration. Des rapports au format PDF ne suffisent pas à garantir une capacité de sortie. Des exports lisibles par machine, accompagnés d’une documentation de schéma, permettent de reconnecter la visibilité.

La responsabilité, les SLA et les preuves de sécurité doivent être discutés au même titre que le périmètre fonctionnel. Pour le matériel IoT, il faut également prévoir l’approvisionnement en pièces détachées, le support du firmware et les obligations liées à la fin de vie. Sans cela, la sortie se solde par des points aveugles liés aux appareils, même si la migration du logiciel est réussie.

Matrice décisionnelle : plateforme d’entreprise versus spécialiste

La décision repose sur le profil de risque du cas d’usage. L’expérience utilisateur de la démo passe au second plan. Les plateformes d’entreprise excellent pour les processus standardisés, une base de données commune, des contrats d’exploitation existants et des pistes d’audit. Les spécialistes se distinguent par un avantage fonctionnel étroit, une maturité commerciale rapide et une intégration à des sources de données de niche.

Une matrice solide pondère la proximité stratégique avec le processus clé, l’effort d’intégration, le risque lié au fournisseur, le time-to-value, le coût total de possession (TCO) sur l’ensemble du cycle de vie et les coûts de sortie. Gartner décrit le TCO comme une vision holistique des coûts au-delà des frontières de l’entreprise et dans le temps : acquisition, exploitation, intégration, formation et remplacement. Dans la pratique, pour la visibilité, les postes clés sont les licences et l’hébergement, l’effort d’intégration et de mapping, l’exploitation et la supervision, les preuves de sécurité, les coûts de migration et de séquestre, ainsi que l’effort de sortie et de reconnexion. Les montants en euros restent spécifiques à chaque entreprise. S’ajoutent à cela la maturité en matière de sécurité, l’adéquation de la feuille de route et la capacité à réutiliser les données dans son propre contexte ERP et TMS.

Là où le suivi ne génère que de la visibilité et reste facilement remplaçable, le spécialiste peut être privilégié. En revanche, lorsque le suivi a un impact sur le pilotage et la facturation, la pression s’oriente vers une plateforme ou, à minima, une architecture satellite stricte. Les formes hybrides sont légitimes si la propriété, les interfaces et la remplaçabilité sont formalisées par écrit.

Le piège réside dans l’étalon de mesure. L’expérience utilisateur de la démo et les annonces de levée de fonds évaluent la maturité commerciale. La maturité opérationnelle se révèle à travers les preuves de sécurité, les références d’intégration, la capacité d’export et la continuité d’activité garantie contractuellement. Les DSI et CDO placent la capacité de sortie comme critère de sélection avant même le pilote.

Pour les DSI et CDO, cela implique une conséquence claire : les startups spécialisées en visibilité peuvent apporter de l’agilité, à condition que la stratégie IT intègre la connectivité, la portabilité des données et la sortie comme livrables prioritaires. Ceux qui ancrent ces éléments dans la due diligence, l’architecture et le contrat intègrent la rapidité des spécialistes sans exposer leur système d’information DACH à des risques opérationnels incontrôlés.

Foire aux questions

Quand un modèle hybride associant une plateforme du groupe et une start-up spécialisée en visibilité reste-t-il viable ?

Les modèles hybrides fonctionnent lorsque le suivi de la visibilité et la gestion des exceptions sont assurés, tandis que la facturation et le contrôle des SLA restent dans l’ERP ou le TMS. La propriété, les interfaces et la possibilité de remplacement doivent être formalisées par écrit. La matrice de décision pondère la proximité avec le processus clé, l’effort d’intégration, les risques liés au fournisseur, le time-to-value, le TCO et les coûts de sortie sur l’ensemble du cycle de vie.

Quelles preuves de sécurité les fournisseurs IoT et de visibilité doivent-ils fournir ?

Les éléments requis incluent les concepts de rôles et droits, le chiffrement en transit et au repos, la journalisation, la séparation des locataires, ainsi que les preuves de tests d’intrusion et de réponse aux incidents. Les références à utiliser sont le CAIQ de la Cloud Security Alliance, la norme ISO/IEC 27001:2022 Annexe A 5.19 à 5.23, le BSI C5:2026 avec 168 critères, et les lignes directrices de l’ENISA concernant l’identité des appareils et les chemins de mise à jour. Pour l’IoT, s’ajoutent l’identité des appareils, les chemins de mise à jour et la gestion des points de terminaison compromis.

Qu’est-ce qui rend un dépôt de garantie (Escrow) techniquement utilisable en cas d’urgence ?

Sont déposés le code source ou les artefacts de déploiement, y compris leurs dépendances et la documentation de build. Les déclencheurs typiques sont l’insolvabilité, l’arrêt du support, la cessation d’activité et le non-respect durable de la maintenance. La vérification jusqu’à la compilation fonctionnelle et l’inspection opérationnelle, ainsi que les instructions documentées de build et d’exploitation, déterminent l’exploitabilité.

Quels contenus d’export le Data Act de l’UE exige-t-il pour la sortie d’un SaaS ?

Depuis le 12 septembre 2025, le chapitre VI du Data Act de l’UE impose aux fournisseurs de services de traitement des données de faciliter la transition. Les contrats doivent préciser les formats, l’exhaustivité, la fréquence et les tests d’export, y compris les événements historiques et la configuration. Les exports lisibles par machine, accompagnés d’une documentation de schéma, permettent de reconnecter la pipeline de visibilité.