Dépendance technologique : comment cartographier ce qu’un fournisseur ne maîtrise pas seul

La dépendance technologique ne se résume pas au pays où se trouve le siège d’un fournisseur. Un service peut dépendre de composants, de logiciels, de sites de fabrication, de compétences et de contrats répartis entre plusieurs acteurs. Pour comprendre sa résilience, il faut identifier ce qui est indispensable, ce qui peut être remplacé et ce qui a réellement été testé. La carte proposée ici est une méthode éditoriale d’analyse, pas une enquête sur une entreprise particulière. Elle aide à transformer une promesse d’autonomie en questions documentables sur le fonctionnement et la reprise.

Partir du service à préserver

Une carte utile commence par le résultat que l’on veut maintenir : produire un composant, servir une application ou assurer une maintenance. Sans cette définition, l’inventaire peut devenir une liste interminable sans priorité. Une dépendance est importante par son effet sur ce résultat. Un élément peu coûteux peut être indispensable, tandis qu’un poste de dépense élevé peut disposer d’alternatives facilement mobilisables.

Le NIST, dans SP 800-161 révision 1 mise à jour, relie les risques de chaîne d’approvisionnement à la criticité des missions, des processus et des systèmes soutenus. Ce document concerne particulièrement la cybersécurité des technologies de l’information et des systèmes opérationnels. La méthode présentée ici s’en inspire pour organiser les questions, sans prétendre que cette référence couvre à elle seule toute la politique industrielle.

La première fiche peut décrire le service, ses utilisateurs, les interruptions tolérables et les données nécessaires. Ces éléments définissent le périmètre. Pour une application, perdre temporairement une fonction secondaire n’a pas le même effet que perdre l’accès aux données. Pour une production, manquer une pièce de remplacement peut avoir un impact différent selon les stocks et les possibilités de réparation.

Il faut éviter de fixer des seuils arbitraires simplement pour remplir une matrice. Le temps acceptable de reprise doit venir des besoins du processus et des conséquences de l’arrêt. Si cette information n’est pas connue, elle devient une question à résoudre. Une carte honnête peut contenir des inconnues ; elle ne doit pas les convertir en faible risque par défaut.

Lecture : Fonction indispensable → Dépendance et fournisseur → Alternative compatible → Qualification documentée. Grille pédagogique ; des retours entre étapes restent possibles.

Suivre les couches sous le fournisseur visible

Le fournisseur direct est souvent le point de contact contractuel, mais il s’appuie lui-même sur d’autres acteurs. Un service numérique peut utiliser un hébergeur, un système d’identité, des bibliothèques et des outils de supervision. Un produit physique peut dépendre de matières, de procédés, d’équipements et de sous-traitants. Il faut examiner les fonctions assurées par ces éléments et leur relation avec le service final.

Le NIST souligne l’asymétrie d’information entre l’acheteur et les fournisseurs. L’acheteur ne voit pas toujours comment la technologie est développée, intégrée ou maintenue. La réponse n’est pas de supposer ce qui manque, mais de demander des informations proportionnées au risque. Le contrat, la documentation technique et le dialogue avec le fournisseur peuvent préciser les responsabilités et les limites de visibilité.

Une cartographie peut commencer par les dépendances directes puis approfondir celles dont la défaillance aurait un impact important. Tout connaître au même niveau est rarement possible. Il faut indiquer jusqu’où la carte a été vérifiée et quels sous-traitants restent non documentés. Cette limite est une partie du résultat. Une absence de donnée ne prouve ni indépendance ni vulnérabilité particulière.

La Cour des comptes européenne, dans son rapport de 2025 sur les puces, illustre la complexité d’une chaîne mondiale associant conception, équipements, matières, fabrication et assemblage. Cet exemple montre pourquoi la localisation d’une seule étape ne décrit pas toute la chaîne. Il ne permet pas d’attribuer une dépendance précise à une entreprise sans enquête complémentaire.

La nationalité est une dimension, pas la carte entière

La localisation peut influencer des risques logistiques, réglementaires ou géopolitiques. Elle doit être documentée quand elle compte. Mais plusieurs fournisseurs de nationalités différentes peuvent partager une même usine, un même composant ou un même service technique. Inversement, deux acteurs situés dans un même pays peuvent disposer de chaînes distinctes. Le nombre de marques visibles ne mesure donc pas automatiquement la diversification.

Il faut distinguer siège, contrôle, localisation des opérations et origine des composants. Ces informations répondent à des questions différentes et peuvent être difficiles à obtenir. Les regrouper sous une seule étiquette de souveraineté masque parfois le point réellement critique. La méthode doit préciser la propriété étudiée et les preuves disponibles, sans déduire les autres à partir de celle-ci.

La dépendance peut également être contractuelle ou intellectuelle. Un logiciel accessible peut nécessiter une licence, une clé, un service d’activation ou une compétence rare pour être maintenu. Un équipement peut être physiquement présent mais difficile à réparer sans support. La propriété matérielle ne suffit donc pas à établir la capacité d’exploitation autonome.

Une alternative existe-t-elle en pratique ?

Trouver un fournisseur proposant une fonction similaire constitue un début, pas une preuve de substituabilité. Les formats, interfaces, performances et conditions de qualification peuvent différer. Une alternative doit être évaluée sur la tâche réelle. Dans une chaîne industrielle, un changement de composant peut nécessiter des essais et une nouvelle validation ; dans un logiciel, une migration peut demander de transformer les données et les intégrations.

Il faut distinguer alternative identifiée, alternative compatible et alternative testée. Cette progression évite de présenter un nom dans un tableur comme un plan de continuité. Les coûts, les délais et les ressources nécessaires à la substitution doivent être estimés avec leurs hypothèses. S’ils n’ont pas été mesurés, l’état doit rester explicite.

Un exemple fictif peut porter sur un service d’analyse documentaire. L’équipe a repéré un autre moteur, mais ses fichiers de sortie diffèrent. La reprise demande d’adapter les contrôles, les interfaces et les cas de test. Le remplacement du moteur n’est donc qu’une partie du travail. Le délai dépend aussi de la disponibilité des personnes et de la qualité de la documentation interne.

Construire une matrice de criticité et de preuve

La grille suivante est un outil de questionnement original. Elle ne donne aucune note à une entreprise réelle. Chaque ligne doit être remplie avec une source, un responsable et une date de vérification.

Dépendance	Effet possible de l’arrêt	Preuve à demander	Alternative à qualifier
Composant	Fonction indisponible	Nomenclature et qualification	Équivalence testée
Logiciel	Traitement interrompu	Versions et interfaces	Migration documentée
Hébergement	Service inaccessible	Architecture et reprise	Environnement compatible
Maintenance	Réparation retardée	Contrat et compétences	Support ou stock validé
Données	Perte de continuité	Export et restauration	Copie exploitable
Compétence	Opération impossible	Procédure et habilitation	Transmission vérifiée

La criticité se discute avec le propriétaire du processus. Une classification peut distinguer plusieurs niveaux, mais elle doit expliquer les critères. Un score sans justification donne une impression de précision sans aider à agir. La preuve peut être un document, un essai ou une confirmation contractuelle ; il faut conserver ce qu’elle établit et ce qu’elle laisse encore inconnu.

Tester la reprise plutôt que seulement la décrire

Un plan de reprise peut prévoir une sauvegarde, mais il faut vérifier que les données peuvent être restaurées dans un environnement utilisable. Un export peut exister sans contenir les relations ou les pièces nécessaires. La recette doit donc porter sur le résultat : le service essentiel fonctionne-t-il avec les éléments récupérés ? Aucun test de ce type n’est rapporté pour une entreprise dans cet article.

Le test peut être limité et réversible. Il peut utiliser un sous-ensemble de données non sensibles, un environnement isolé et une opération représentative. L’objectif est de découvrir les dépendances oubliées sans provoquer une interruption réelle. Les résultats doivent conserver les versions, les difficultés et le temps observé, sans extrapoler automatiquement à une reprise complète.

Une dépendance peut apparaître pendant cet exercice : accès à une personne, licence secondaire, format ancien ou procédure non écrite. La carte doit être mise à jour avec cette découverte. Elle devient ainsi un outil de maintenance et non une photographie destinée uniquement à un audit. Le processus de revue doit préciser quels changements déclenchent une nouvelle vérification.

Choisir une réponse proportionnée

Réduire une dépendance peut passer par la diversification, un stock, une documentation, une formation ou un changement d’architecture. Il n’existe pas une réponse unique. Ajouter un fournisseur peut coûter cher et complexifier la maintenance ; conserver une seule source peut être acceptable si le risque est compris et limité. Le NIST rappelle que les contrôles demandent des ressources et doivent être discutés au regard des risques et des bénéfices.

La décision doit donc exposer le compromis. Quelle interruption cherche-t-on à éviter ? Quel coût et quel travail la mesure ajoute-t-elle ? Quelle preuve montre qu’elle améliore la situation ? Une solution qui déplace la dépendance vers un composant moins visible doit être décrite comme telle. L’objectif n’est pas de prétendre éliminer toutes les relations extérieures, mais de mieux maîtriser les conséquences des relations indispensables.

Ce qui compte est de pouvoir expliquer la continuité du service au-delà du fournisseur visible. Une carte fiable relie fonctions, composants, responsabilités et alternatives vérifiées. Elle conserve les inconnues et les délais non mesurés. Cette approche rend la discussion sur l’autonomie plus concrète : elle parle de ce que l’on sait faire, de ce que l’on peut remplacer et de ce qu’il faut encore démontrer.

Garder une preuve à côté de chaque lien

Dans la carte, chaque relation devrait porter un statut : déclarée par le fournisseur, documentée dans un contrat ou vérifiée par un essai. Cette distinction évite de donner la même valeur à une brochure et à une restauration effectivement exécutée. Un lien non confirmé reste une piste à approfondir. Il ne doit pas devenir une accusation ni disparaître au motif qu’il est difficile à vérifier.

La date compte également. Un fournisseur peut changer de sous-traitant ou de configuration, tandis que l’acheteur modifie son propre usage. La carte doit préciser les événements qui déclenchent une mise à jour : nouvelle version, nouveau site, changement contractuel ou incident. L’objectif est de maintenir une représentation utile, pas de promettre une connaissance exhaustive de toutes les entreprises de la chaîne.

Enfin, l’accès à cette carte doit être proportionné à son contenu. Elle peut révéler des fragilités ou des informations contractuelles. Une synthèse publique peut présenter la méthode et les limites sans exposer les détails sensibles. La transparence sur la démarche n’exige pas la publication de chaque dépendance opérationnelle.

Pour prolonger cette lecture : Chips Act : distinguer les objectifs européens des capacités déjà disponibles.

Sources

• NIST, SP 800-161 révision 1 mise à jour 1, section 1.5.2 et passage « Managing Cost and Resources », consultés le 19 octobre 2026 ; champ cybersécurité des chaînes technologiques.
• Cour des comptes européenne, rapport spécial 12/2025, paragraphes 1 à 3 et schéma de chaîne de valeur, consultés le 19 octobre 2026.