La maîtrise est plus importante que la forme de propriété d'un outil
Une dépendance inutile apparaît lorsqu'un fournisseur ne fournit pas seulement une fonction, mais devient de fait propriétaire de l'accès aux données, des connaissances sur les processus ou de la capacité d'action opérationnelle.
Les entreprises réduisent ce risque grâce à des responsabilités documentées, des données exportables, des interfaces ouvertes ou du moins documentées, des accès indépendants, des contrats traçables et un scénario de sortie réaliste. Une indépendance totale est rarement rentable. L'objectif est une dépendance maîtrisée.
Situation de départ
Fin 2022, la gamme d'outils numériques de nombreuses entreprises s'était considérablement développée. Sites web, newsletters, CRM, analyse, prise de rendez-vous, gestion de projet, stockage de fichiers et campagnes étaient souvent connectés via des services spécialisés.
Cette division du travail présentait de nets avantages. Les fonctionnalités pouvaient être introduites plus rapidement. Le développement interne n'était pas nécessaire pour chaque cas d'usage. Les mises à jour, la sécurité et l'exploitation incombaient en partie au fournisseur.
Simultanément, des dépendances sont apparues, qui ne sont visibles qu'en cas de changement, d'augmentation des prix, de panne ou de fin de relation avec un prestataire. Les identifiants de connexion étaient détenus par des individus. Les données ne pouvaient être exportées que partiellement. Les automatisations n'étaient pas documentées. Le contenu était lié à des éléments de page propriétaires. Une fonction centrale dépendait d'une seule extension.
Le problème ne résidait pas dans l'utilisation d'outils externes. C'était l'absence de décision architecturale sur les parties externalisables et celles dont les bases doivent rester maîtrisables en interne.
Ce qui se cache derrière le problème
Fonction et système sont confondus
Un outil résout une tâche concrète. Un système relie les tâches, les données, les rôles et les transferts. Si la décision relative à l'outil est prise sans perspective systémique, chaque département optimise sa propre section.
Le CRM correspond aux ventes, le formulaire au marketing et le site web au design actuel. La question de savoir si les formats de données, les consentements, les responsabilités et les interfaces s'accordent sera réglée plus tard. La dépendance ne naît ainsi pas seulement envers le fournisseur, mais envers la combinaison accumulée.
La commodité masque les coûts de changement
Un service peut être très simple au quotidien et générer des coûts considérables lors du changement. Les frais de licence ne sont pas les seuls éléments à considérer. Les coûts de changement comprennent:
- Nettoyage et migration des données
- Nouvelle construction d'interfaces
- Formation et adaptation des processus
- Perte de données historiques ou de métadonnées
- Reconstruction des automatisations non documentées
- retouches techniques sur le site web ou les formulaires
- risques opérationnels temporaires
Ces coûts ne constituent pas en soi un argument contre un outil. Ils doivent être identifiés avant la prise de décision.
L'exportation de données est assimilée à la portabilité
De nombreux systèmes proposent une fonction d'exportation. Cependant, une exportation ne garantit pas à elle seule une possibilité réelle de migration. Les données peuvent être incomplètes, mal documentées ou se trouver dans un format qui supprime les relations et l'historique.
La portabilité exige donc davantage : quelles données sont exportées ? Les pièces jointes, les états, les associations et les preuves de consentement sont-ils inclus ? Peuvent-ils être importés de manière judicieuse dans un autre système ? La structure est-elle documentée ?
Les connaissances restent chez les prestataires ou les individus
Une solution technique peut appartenir formellement à l'entreprise et, en pratique, rester incontrôlable. Cela se produit lorsqu'une seule personne externe connaît les accès, l'hébergement, les extensions, les interfaces ou la logique spécifique.
La dépendance n'est alors pas qu'un problème de produit. C'est un problème de documentation et de responsabilité.
Positionnement stratégique
Les normes ouvertes créent des possibilités de changement et de connexion
Les lignes directrices officielles sur les standards ouverts soulignent depuis des années l'interopérabilité, l'échange de données et la prévention d'une dépendance inutile envers les fournisseurs. Les standards ouverts ne garantissent pas une migration facile. Ils augmentent toutefois la chance que les systèmes puissent être reliés ou remplacés via des formats et des interfaces documentés.
Pour les entreprises, cela ne signifie pas qu'il faille utiliser exclusivement des logiciels ouverts. Les services propriétaires peuvent s'avérer judicieux sur le plan technique et économique. L'élément décisif est de savoir si les données et processus critiques restent dans des structures compréhensibles et accessibles.
Le noyau et les modules doivent être séparés
Une architecture solide distingue le noyau propre à l'entreprise des modules interchangeables.
Le cœur comprend généralement :
- Domaines et comptes centraux
- contenus et fichiers partagés
- Données clients et de contact dans le cadre légal autorisé
- Documentation des processus et des interfaces
- Rôles et autorisations d'accès
- Définitions de mesure
- justificatifs contractuels et techniques
Les modules peuvent être l'hébergement, le CMS, les newsletters, la prise de rendez-vous, l'analyse ou l'automatisation. Ils peuvent être importants. Mais ils ne doivent pas rendre le cœur inaccessible.
La capacité de sortie fait partie de la décision de sélection
Un plan de migration n'est pas une annonce de quitter prochainement le fournisseur. C'est un test de sa propre capacité d'action.
Avant une mise en œuvre critique, les entreprises devraient clarifier :
- Quelles données et quels contenus doivent être entièrement exportables ?
- Quelles interfaces sont utilisées ?
- Qui possède les accès administratifs ?
- Quels délais de préavis et coûts supplémentaires s'appliquent ?
- Combien de temps l'exploitation peut-elle se poursuivre sans le service ?
- Quelle solution de rechange serait envisageable en principe ?
Ces questions améliorent souvent déjà l'utilisation en cours.
Perspective pratique
Les dépendances deviennent souvent visibles lors des refontes de sites web. Le contenu peut certes être exporté, mais les structures de pages, les formulaires ou les modules individuels font défaut. L'entreprise possède ses textes, mais pas la logique fonctionnelle.
Un schéma similaire apparaît avec les automatisations. Un processus fonctionne pendant des années. Dès que la personne responsable fait défaut, il n'est plus possible de comprendre quelles données sont transférées à quel système et comment les erreurs sont détectées.
La contre-mesure pratique ne consiste pas en un développement technique interne complet. Il s'agit d'une documentation minimale fiable : finalité du système, propriétaire, accès, types de données, interfaces, dépendances, sauvegarde, coûts, délais contractuels et possibilité de sortie.
La base système propre à l'entreprise
Cadre d'action
1. Déterminer la criticité
Évaluez quels outils sont essentiels pour le chiffre d'affaires, la communication client, l'exploitation du site web ou les obligations de preuve. Plus la fonction est critique, plus les exigences en matière d'accès, de documentation et de possibilité de changement sont élevées.
2. Assurer le contrôle administratif
Les comptes centraux, les domaines, l'hébergement et la facturation doivent être attribués à l'entreprise. Les partenaires externes reçoivent des rôles appropriés, mais pas le contrôle unique.
3. Tester l'exportation en pratique
Ne vous fiez pas à une description de fonction. Pour les systèmes critiques, effectuez une exportation de test et vérifiez l'exhaustivité, le format et la réutilisabilité.
4. Documenter les interfaces
Notez quelles données circulent où, quels déclencheurs s'appliquent et comment les erreurs sont détectées. Documentez également les transferts manuels.
5. Définir le scénario de sortie
Définissez comment une transition ordonnée pourrait se dérouler. Le scénario ne doit pas être élaboré dans les moindres détails techniques. Il doit montrer que les données, l'accès et la responsabilité ne résident pas entièrement chez le fournisseur.
Ce que les entreprises ne doivent pas faire
Les entreprises ne doivent pas évaluer la dépendance uniquement sur la base des coûts de licence ou du terme "Cloud". Une solution personnalisée non documentée et exploitée en local peut lier plus fortement qu'un service cloud bien documenté doté d'interfaces ouvertes.
Il est tout aussi faux de supposer que chaque outil doit pouvoir être remplacé à tout moment sans effort. La spécialisation crée consciemment des dépendances. La question stratégique est de savoir si l'utilité, le risque et les coûts de changement sont transparents et assumés.
Conséquence pour les entreprises
La souveraineté numérique ne naît pas du renoncement aux fournisseurs. Elle naît de décisions claires en matière de propriété, d'accès et d'architecture.
Une entreprise reste capable d'agir lorsqu'elle connaît ses données, documente ses processus, contrôle les accès centraux et peut évaluer de manière réaliste les possibilités de changement. Ainsi, les outils deviennent des modules du système et non ses propriétaires.
Connexion technique
Vérifier les dépendances système avant l'extension ou le changement
Une architecture système numérique organise les données critiques, les outils, les interfaces, les rôles et les risques de changement. SDC-Discovery peut saisir et prioriser cette situation initiale de manière structurée avant un relancement, une consolidation ou l'introduction de nouveaux systèmes.
Clarifier le paysage des systèmes numériques et les dépendances
Sources et bases techniques (5)
- Government Digital Service, Principes des standards ouverts, 2018. Ouvrir la source
- Government Digital Service, Working with open standards, disponible avant décembre 2022. Ouvrir la source
- Government Digital Service, Managing technical lock-in in the cloud, 2019. Ouvrir la source
- National Institute of Standards and Technology, NIST Cloud Computing Standards Roadmap, Special Publication 500-291 Revision 2, 2013. Ouvrir la source
- Union européenne, Règlement général sur la protection des données, Article 20 sur la portabilité des données. Ouvrir la source
