Aller au contenu principal

Souveraineté numérique : une checklist pour les conseils d’administration suisses

Six dimensions, six preuves et une décision que l’organisation peut réellement exécuter.

An empty boardroom overlooking Swiss foothills. / Leerer Sitzungsraum mit Blick auf Schweizer Voralpen. / Salle de réunion vide face aux Préalpes suisses.
AI illustration · KI-Illustration · Illustration générée par IA

Une discussion utile sur la souveraineté numérique commence par un service que l’organisation doit pouvoir maîtriser. Choisissez la paie, les commandes clients, la planification clinique ou un autre processus dont l’interruption a des conséquences précises. Que pourrait encore décider et exécuter l’organisation si un fournisseur essentiel devenait indisponible ?

La réponse demande des preuves : une restauration exercée, un export utilisable, une suppléance autorisée, un contrat examiné. Une liste de fournisseurs ne montre pas comment ces éléments fonctionnent ensemble.

Les recommandations fédérales de cybersécurité destinées aux entreprises et aux autorités placent les décisions de risque et de continuité au niveau de la direction et soulignent les responsabilités liées à l’informatique externalisée. Cette checklist accompagne la discussion opérationnelle. Elle ne certifie aucune conformité juridique ou réglementaire.

Commencer par un service bien délimité

Notez le service, les personnes concernées, l’interruption tolérable et le résultat métier à préserver. La direction précise cette tolérance et son raisonnement avant l’exercice. Le conseil peut ensuite examiner si les moyens, les pouvoirs de décision et les preuves sont cohérents.

Examinez le même service à travers les six dimensions de l’Observatory. Qualifiez chaque réponse de démontrée, documentée mais non testée, ou inconnue. Ces mentions servent aux notes de travail ; elles ne remplacent pas l’échelle d’évaluation de l’Observatory.

1. Souveraineté de l’infrastructure

Demandez à l’équipe de montrer le passage du fonctionnement normal à une solution de secours testée. Incluez l’électricité, le réseau, le stockage, les identités et l’accès aux instructions de restauration. Un second environnement dépendant de la même connexion ou authentification indisponible peut tomber au même moment.

Demandez le dernier compte rendu de restauration : éléments restaurés, durée, données manquantes et contrôle du résultat métier. Conservez les étapes qui ont échoué. Elles indiquent où investir ou ajuster les attentes.

Preuve à demander : un exercice de restauration daté, avec son périmètre, son résultat observé et les défauts non résolus.

2. Souveraineté du cloud et des plateformes

Choisissez une dépendance SaaS ou cloud importante et examinez la sortie. Demandez un petit export représentatif, puis montrez qu’un autre environnement peut le lire. Incluez identifiants, relations, pièces jointes, autorisations et historique nécessaire à l’activité.

Examinez ensuite préavis contractuel, coût d’extraction, effort de mise en œuvre, accès au support et personnes nécessaires en interne. Un droit de sortie négocié devient utilisable lorsque quelqu’un peut expliquer et démontrer le chemin.

Preuve à demander : un export et un import testés, accompagnés des contraintes commerciales et opérationnelles restantes.

3. Souveraineté des données

Suivez un ensemble de données sensibles à travers collecte, traitement, sauvegardes, accès du support et suppression. Recensez lieux, organisations, identités autorisées et base contractuelle de chaque transmission. Incluez les journaux et les copies utilisées pour les tests.

Les spécialistes des données et du droit évaluent les obligations applicables au service réel. Une indication de localisation ne décrit pas tous les accès et traitements. Le conseil doit pouvoir distinguer ce qui a été évalué de ce qui reste ouvert.

Preuve à demander : une carte actuelle des flux reliée aux revues d’accès, aux conditions de sous-traitance et aux décisions de conservation.

4. Souveraineté de l’IA

Choisissez un processus assisté par IA et retracez ses entrées, sa dépendance au modèle et ses actions possibles. Quelles données peuvent sortir de l’organisation, quels résultats nécessitent une revue et qui peut arrêter le processus ? Prévoyez aussi le traitement d’un résultat déjà transmis à un client ou à un système en aval.

Demandez une démonstration limitée du secours : revue humaine, service réduit ou alternative déjà testée. Un autre modèle peut se comporter différemment ; son adoption exige des contrôles sur la même tâche métier.

Preuve à demander : une personne responsable, des limites d’action, des critères de surveillance et une procédure d’arrêt ou de secours testée.

5. Souveraineté des applications et des logiciels

Une personne autre que l’auteur initial doit pouvoir construire, déployer et exploiter une partie représentative du service à partir des instructions maintenues. Vérifiez l’accès prévu au code source, aux dépendances, aux licences, aux artefacts de version, aux identifiants et au savoir opérationnel.

Cet exercice rend la maintenabilité visible. Il peut révéler un compte non documenté indispensable au build, ou une étape de restauration connue d’une seule personne. Notez la dépendance sans blâmer la personne qui l’a assumée jusque-là.

Preuve à demander : un compte rendu de construction et de restauration reproductibles, réalisé par une seconde personne.

6. Gouvernance et achats

Nommez la personne qui peut accepter l’interruption, celle qui peut autoriser le secours et celle qui peut l’exécuter. Précisez les suppléances et les limites des délégations. Vérifiez la continuité de ces responsabilités pendant les congés, les changements de personnel et les renouvellements de contrat.

Pour le prochain achat, examinez les coûts de sortie et d’exploitation avec le prix d’acquisition. Consignez les dépendances acceptées : par qui, pour quelles raisons proportionnées et avec quels déclencheurs de réexamen.

Preuve à demander : une décision documentée avec responsable, budget, limites et déclencheurs de revue.

Transformer la revue en un document de travail

Reprenez cette structure pour chaque service critique :

  • Service et résultat métier à préserver.
  • Tolérance d’interruption et personne habilitée à l’accepter.
  • Preuves pour les six dimensions, avec date et périmètre du dernier test.
  • Limites connues, dépendances communes et questions ouvertes.
  • Prochaine correction, responsable et date de revue convenue avec cette personne.

Une restauration inexistante ne doit pas disparaître dans une moyenne rassurante. Une seule dépendance non testée peut déterminer la capacité du service à continuer. Répétez l’exercice limité après une modification importante du fournisseur, de l’architecture, des flux de données ou de l’équipe.

Cette checklist prolonge La souveraineté numérique n’est pas du nationalisme, La souveraineté se mesure en temps de réponse et La préparation est la forme la plus élevée de souveraineté. Ces textes interrogent la marge de manœuvre que conserve l’organisation.

Commencez par l’Observatory pour situer la dimension la moins comprise. Apportez un service et ses preuves dans une Conversation lorsque la prochaine décision demande un examen plus précis.