Les accords start-up exigent une clause de sortie IT

07.07.2026

6 min de lecture

Les startups apportent de la vitesse. Les services métiers veulent cette même rapidité en phase pilote et de scaling. Sans plan de sortie et d’intégration, l’IT reste bloquée sur des stacks fantômes, des flux de données flous et des contrats qui, en cas de problème, sont à peine applicables.

Les points clés en bref

Peu de collaborations avec des startups. Selon Bitkom 2025, seulement 31 % des entreprises collaborent avec des startups ; là où cela fonctionne, la sécurité et l’architecture sont souvent mises en place après le pilote, générant une IT fantôme.
Sécurité et identités avant le pilote. Norme C5:2026, IAM d’entreprise avec SSO et MFA, ainsi que la résidence des données et les sous-traitants formalisés par écrit doivent être en place avant le premier utilisateur en production.
Pièges du scaling au niveau des API et des licences. Des API instables, des clauses de true-up et un support sans SLA mesurables rendent la montée en puissance coûteuse ; la due diligence technique doit précéder l’autorisation de scaling.
Sortie opérationnelle et scorecard du DSI. Les formats d’export, les preuves de suppression et les services de transition rendent la sortie IT tangible ; la scorecard évalue l’IAM, la résidence des données, les API, les licences, le support et la sortie avant pilote et scaling.

Articles associésCorporate Venture Building : créer des startups au sein d’un groupe / Pourquoi les startups perdent malgré des milliards de clients

Motivations types des accords et angles morts IT courants

Les motivations derrière les accords entre grands groupes et startups sont généralement compréhensibles. Les services métiers recherchent une accélération du retour sur investissement, un accès à une compétence de niche ou une preuve de concept qui prendrait des mois en interne. Selon l’étude Bitkom « La digitalisation de l’économie » (2025), seulement 31 % des entreprises collaborent sous une forme ou une autre avec des startups ; deux tiers (67 %) ne le font pas. Là où cela fonctionne, les achats et l’innovation pilotent souvent via des contrats-cadres, des budgets dédiés ou des dispositifs de corporate venture, en évaluant surtout la capacité de livraison et le prix. Le guide Nesta « Winning Together » (avec Startup Europe Partnership) souligne que l’achat auprès de startups exige une approche différente en termes de processus et de gestion des risques par rapport à l’achat classique auprès de fournisseurs – et que des registres fournisseurs rigides ou des conditions de paiement bloquent souvent ces collaborations.

Les angles morts IT ne naissent que rarement d’une mauvaise intention. Ils apparaissent parce que la sécurité, l’architecture et le modèle opérationnel ne sont mobilisés qu’après le pilote. Le startup est alors déjà ancré dans les processus métiers, des comptes utilisateurs parallèles existent et les données résident dans des régions cloud non validées par le groupe. Une refonte ultérieure coûte plus cher qu’une validation propre avant le lancement.

Les angles morts typiques concernent les identités, la journalisation, les sauvegardes et la question de savoir qui peut réellement gérer la stack en cas de perturbation. On observe aussi souvent l’absence de déclarations claires sur les sous-traitants, la résidence des données et l’intégration aux systèmes existants. Ce qui commence comme un pilote isolé devient ainsi une IT parallèle avec sa propre gouvernance.

Sécurité, identités et résidence des données avant le pilote

La due diligence en matière de sécurité doit précéder le pilote, et non suivre le premier utilisateur en production. Basée sur le catalogue de critères C5:2026 du BSI – le *Cloud Computing Compliance Criteria Catalogue* de l’Office fédéral allemand de la sécurité des technologies de l’information –, elle impose un socle minimal : un concept de rôles et de droits, un chiffrement en transit et au repos, une journalisation avec des durées de conservation vérifiables, ainsi que la clarification des types de données traitées par la startup (données personnelles ou données métiers). Le C5 fournit aux clients du cloud une base vérifiable pour leur propre gestion des risques et exige une transparence sur les sites, les sous-traitants et les responsabilités partagées.

Les identités constituent le levier le plus fréquent… et la source d’erreurs la plus courante. Sans intégration au système IAM (Identity and Access Management) du groupe – c’est-à-dire la gestion centralisée des identités et des droits d’accès –, on assiste à la prolifération de comptes locaux, de mots de passe partagés et d’utilisateurs orphelins après un changement de personnel. L’authentification unique (SSO), l’authentification multifacteur (MFA) obligatoire et un processus documenté de désactivation des accès doivent figurer dans le contrat et le concept opérationnel avant que des données clients réelles ou des données de production ne circulent.

La résidence des données et le traitement des données par un sous-traitant ne sont pas des détails à régler après coup dans la région DACH. La Commission européenne a publié, via la décision d’exécution (UE) 2021/915, des clauses contractuelles types entre responsables de traitement et sous-traitants conformément à l’article 28 du RGPD ; elles encadrent notamment l’obligation de se conformer aux instructions, les sous-traitants secondaires et la gestion des données à la fin du contrat. Les lieux de traitement, les sous-traitants, l’emplacement des sauvegardes et la question d’éventuels accès au support depuis des pays tiers doivent être formalisés par écrit avant le pilote. Qui attend le scale pour régler ces points négocie sous pression et avec un environnement opérationnel déjà en cours.

Pièges liés aux API, licences et support lors du scale

Lors du scale, de nombreux accords échouent au niveau des interfaces. L’idée initiale reste souvent viable, mais l’intégration est la première à montrer des faiblesses. Des API manquantes ou instables imposent des exports manuels, des intégrations parallèles non documentées et une double gestion des données. Les limites de débit, les champs non documentés et les modifications disruptives sans stratégie de versionnage rendent l’exploitation coûteuse et les rapports peu fiables. Une vérification des API et des intégrations doit donc faire partie de la due diligence technique avant l’autorisation de scaling.

Les pièges liés aux licences n’apparaissent souvent qu’avec la croissance du nombre d’utilisateurs. Les modèles par siège, les packs de modules, les tarifications basées sur des métriques et les frais pour les environnements supplémentaires peuvent faire exploser les coûts initialement prévus. Dans les contrats SaaS et logiciels, les clauses de *true-up* sont courantes : le fournisseur ajuste périodiquement l’utilisation réelle avec la quantité sous licence et facture les dépassements. Les droits d’audit complètent souvent ce dispositif avec des délais de préavis et la prise en charge des coûts si la sous-licence dépasse un seuil (souvent entre 5 et 10 %). Tout aussi critique sont les restrictions concernant la transmission des droits d’utilisation à des sociétés du groupe.

Le support représente un risque opérationnel lors du scale. Les temps de réponse, les circuits d’escalade, la disponibilité en astreinte et la question de savoir si le support est uniquement en anglais et limité à certaines zones horaires doivent être clarifiés avant le déploiement. Sans SLA assorti d’objectifs mesurables et sans interlocuteur désigné, le service métier se retrouve seul face au CIO en cas d’incident, malgré la promesse contractuelle d’un « support inclus ».

Clauses de sortie qui fonctionnent vraiment

Un départ d’un prestataire IT n’est efficace que s’il est opérationnellement réalisable. L’article 28, paragraphe 3, point g du RGPD exige que le sous-traitant, à la fin du traitement, supprime ou restitue les données personnelles à la demande du responsable de traitement, et efface les copies existantes, sauf obligation légale de conservation. Les clauses contractuelles types de la Commission européenne (2021/915) déclinent ces exigences sur le plan opérationnel. Il est donc nécessaire de prévoir des délais et formats pour l’export des données, la complétude de la restitution, les preuves de suppression et la gestion des données dérivées ainsi que des logs.

L’escrow (séquestre) et l’accès au code source ne sont pas des remèdes miracles, mais dans des dépendances critiques, ils constituent un outil pertinent. L’escrow n’a de sens que si les conditions de déclenchement sont clairement définies, si la version déposée est maintenue à jour et si l’équipe IT interne dispose des compétences nécessaires pour exploiter le code. Sans documentation de build et d’exploitation, l’escrow n’est qu’un apaisement coûteux.

Les services de transition après la résiliation déterminent la réalité du départ. Ils incluent notamment l’exploitation parallèle temporaire, les obligations de coopération de la startup lors de la migration et l’interdiction de rendre l’export artificiellement complexe. Tout aussi pertinent est la clarification de qui pourra encore maintenir les interfaces et connecteurs après le départ. Qui ne règle pas ces points à l’avance s’expose à un second projet en parallèle de la migration déjà en cours.

Fiche d’évaluation pour le point d’approbation du DSI

Une fiche d’évaluation du DSI transforme les points mentionnés en une logique d’approbation avant le pilote et avant le passage à l’échelle. La norme ISO/IEC 27001:2022 exige, dans les contrôles de l’annexe A (A.5.19 à A.5.22), des processus pour la sécurité de l’information dans les relations avec les fournisseurs, des exigences de sécurité dans les contrats, le contrôle de la chaîne d’approvisionnement et un suivi continu. Le référentiel BSI-C5 offre, en complément, aux clients cloud une orientation vérifiable pour le choix et la gestion des risques. Au minimum, il convient d’évaluer : l’intégration IAM, la classification et la résidence des données, les preuves de sécurité de base, la maturité des API et des intégrations, le modèle de licence et de coûts lors de la montée en charge, le modèle de support et d’exploitation ainsi que la capacité de sortie, y compris l’exportation et la suppression des données.

Chaque point doit avoir un responsable et un statut clair : approuvé, approuvé sous conditions ou bloqué. Des conditions sans échéance ni obligation de preuve ne constituent pas une gestion efficace. Pour le passage à l’échelle, la fiche d’évaluation doit être plus stricte que pour un pilote isolé, car le nombre d’utilisateurs, le volume de données et la dépendance aux processus augmentent.

La fiche d’évaluation ne freine pas l’innovation. Elle empêche que la rhétorique innovante des métiers ne minimise les risques IT comme des problèmes résolubles ultérieurement. Le point d’approbation du DSI est le moment où rythme et maîtrise des risques doivent être conciliés. Son absence conduit à une informatique « start-up » interne sans due diligence IT sérieuse ni clauses de sortie opérationnelles.

Approuver des partenariats avec des startups sans clause de sortie IT revient à acheter de la vitesse à crédit. Le prix se paiera plus tard avec des empilements technologiques non maîtrisés, des surprises liées aux licences et des projets de migration sous pression. La conséquence logique pour le DSI et le CDO est simple : chaque pilote nécessite une base solide en sécurité et en identité, chaque passage à l’échelle exige une clarté sur les API, les licences et le support, et chaque contrat doit inclure une clause de sortie testable en conditions réelles.

Foire aux questions

À quel point la CIO-Scorecard doit-elle être stricte pour un pilote isolé par rapport à une mise à l’échelle ?

Pour le pilote, l’intégration IAM, la classification des données, la résidence et les preuves de sécurité de base sont requises comme autorisation minimale avant que les données clients ne circulent. Le processus de mise à l’échelle doit être plus exigeant, car le nombre d’utilisateurs, le volume de données et la dépendance aux processus augmentent, et la clarté concernant les API, les licences ainsi que le support devient indispensable. Chaque point nécessite un responsable et un statut : validé, validé sous conditions ou bloqué. Les conditions sans échéance ni obligation de preuve ne permettent pas de maîtriser l’accord commercial.

Quand un dépôt de code source (Escrow) est-il pertinent en cas de dépendance critique à une startup ?

L’Escrow est un outil adapté aux dépendances critiques lorsque les déclencheurs sont clairement définis, que la version déposée est maintenue à jour et que l’équipe IT interne dispose des compétences pour construire et exploiter le système. Si la documentation opérationnelle fait défaut, l’Escrow reste une solution coûteuse pour se rassurer. Il complète la clause de sortie, mais ne remplace ni l’export des données dans les formats convenus ni les prestations transitoires limitées dans le temps après la résiliation.

Comment vérifier, avant la signature, si les clauses de sortie fonctionnent opérationnellement ?

Prévoir et, si possible, simuler à l’avance : les délais et formats d’export des données, l’exhaustivité de la restitution, les preuves de suppression ainsi que le traitement des données dérivées et des logs. Sécuriser contractuellement un fonctionnement parallèle limité dans le temps, les obligations de coopération lors de la migration et l’interdiction de complexifier artificiellement l’export. Il convient également de clarifier qui pourra assurer la maintenance des interfaces et connecteurs après la sortie.

Pourquoi les processus d’achat standard échouent souvent trop tard dans le cadre de contrats avec des startups ?

Les services Achats et Innovation évaluent souvent la capacité de livraison et le prix via des contrats-cadres ou des budgets d’innovation, tandis que les aspects sécurité, architecture et modèle opérationnel ne sont pris en compte qu’après le pilote. Nesta et Startup Europe Partnership soulignent que l’achat auprès de startups nécessite une approche différente en termes de processus et de gestion des risques par rapport à l’achat classique auprès de fournisseurs. Des procédures rigides d’enregistrement des fournisseurs et des conditions de paiement bloquent les collaborations, tandis que des identités non clarifiées, des sous-traitants et des API entraînent ultérieurement une informatique fantôme.