conseil fédéral

Quand on évoque le conseil fédéral, l'image qui vient est souvent celle d'une institution politique, d'un collège de sept membres, de décisions rendues à Berne. Mais pour un ingénieur, le conseil fédéral est d'abord un opérateur de systèmes: il fixe des spécifications, coordonne des registres, arbitre des budgets d'infrastructure et signe des contrats d'interface entre administrations. Cette lecture technique est rarement documentée, et c'est pourtant la plus utile pour comprendre comment la suisse évite le chaos numérique malgré une architecture fédéraliste à 26 cantons.

Au cours des cinq dernières années, la Confédération suisse a accéléré sa transformation numérique. La stratégie Administration numérique suisse 2024-2027, adoptée par le conseil fédéral fin 2023, fixe des objectifs mesurables autour des prestations en ligne, de l'identité électronique et du partage de données. Dans les coulisses, cela se traduit par des choix d'architecture, des normes d'API et des politiques de sécurité qui intéressent directement les équipes d'ingénierie.

Le vrai pouvoir numérique du conseil fédéral ne réside pas dans ses communiqués, mais dans les standards eCH, les politiques de résidence des données et les contrats d'API qui contraignent chaque canton.

Le Conseil fédéral comme opérateur de plateformes numériques

La Confédération suisse fonctionne comme une architecture distribuée: 26 cantons autonomes, des centaines de communes et une couche fédérale qui coordonne. Le conseil fédéral joue le rôle d'un orchestrateur de plateforme. Il ne développe pas toutes les applications, mais il impose des protocoles d'échange, des formats de données et des mécanismes d'authentification. C'est exactement le modèle d'une plateforme API-first: des services décentralisés, une gouvernance centralisée, des contrats d'interface stricts.

Concrètement, la Confédération opère plusieurs composants partagés: la passerelle d'accès aux services en ligne, l'infrastructure d'échange sécurisé sedex et des registres de référence. Ces briques sont maintenues comme des services internes avec des SLO, des journaux d'audit et des procédures d'onboarding. Dans des mandats d'ingénierie pour des services publics suisses, nous avons constaté que la difficulté n'est presque jamais le code métier, mais l'alignement sur ces contrats fédéraux.

Cette approche n'est pas sans friction. Chaque canton conserve des compétences propres, ce qui rappelle un cluster Kubernetes multi-tenant: les namespaces sont isolés, mais les politiques de réseau et de quotas sont communes. Le conseil fédéral définit les NetworkPolicy de la fédération, tandis que les cantons gèrent leurs propres déploiements.

Stratégie suisse de cyberadministration: standards eCH et interopérabilité

Les standards eCH sont le socle d'interopérabilité de l'administration suisse. Ils décrivent des modèles de données, des enveloppes de messages et des profils d'échange pour les registres des habitants, les annonces de mutation, les dossiers électroniques ou les justificatifs numériques. Pour un développeur, un standard eCH est l'équivalent d'un schéma JSON ou d'un contrat gRPC publié: il évolue avec versioning, passe par des consultations publiques et impose une rétrocompatibilité réfléchie.

L'adoption des standards eCH par les cantons n'est pas uniforme. Dans un audit d'interopérabilité que nous avons mené pour une plateforme cantonale, le principal problème n'était pas l'absence de documentation, mais la divergence entre la version locale d'un modèle de personne et la version fédérale attendue. Les champs étaient similaires, mais les cardinalités et les valeurs autorisées différaient. Ce type de dérive est classique dans les architectures fédérées: sans validation automatique des contrats, la compatibilité se dégrade silencieusement.

La leçon technique est claire: il faut traiter les standards eCH comme des dépendances logicielles. Des outils comme OpenAPI 3. 1, JSON Schema et des validators en CI/CD permettent de détecter les ruptures avant la mise en production. Voir aussi: modéliser des API REST avec OpenAPI et JSON Schema. Le conseil fédéral gagnerait à publier des schémas exécutables, pas seulement des documents PDF.

Identité électronique: architecture technique et controverses du projet e-ID

Le projet d'identité électronique suisse illustre les tensions entre souveraineté, confiance et faisabilité technique. La première loi sur l'e-ID, acceptée par le Parlement puis rejetée en votation en 2021, déléguait la vérification d'identité à des fournisseurs privés. D'un point de vue architectural, cela créait une asymétrie de contrôle: les attributs d'identité étaient émis par des acteurs commerciaux, tandis que l'État restait responsable de la confiance globale. Le référendum a mis en évidence un défaut de conception, pas seulement un désaccord politique.

Le nouveau projet, porté par le conseil fédéral, confie l'émission de l'identité électronique à la Confédération. Sur le plan technique, il devra s'appuyer sur des protocoles éprouvés comme OAuth 20 (RFC 6749) et OpenID Connect, avec des jetons signés (JWT) et des preuves à divulgation sélective. L'enjeu majeur est la révocation, la rotation des clés et la gestion des portefeuilles numériques sur mobile, dans la lignée du règlement européen eIDAS 2. 0 et de la norme ISO/IEC 18013-5 pour le permis de conduire mobile.

En production, nous savons que l'identité ne se résume pas au protocole d'authentification. Il faut aussi traiter la preuve de possession, le rebinding d'identifiant et la corrélation entre canaux. Un système national d'e-ID doit résister à des attaques sophistiquées, pas seulement à des mots de passe faibles. Le conseil fédéral devra publier des profils d'implémentation précis, sinon chaque canton réinventera sa propre variante.

Gouvernance des données publiques et registres de référence

La Suisse dispose de registres de référence solides: registre des entreprises et établissements, registre des bâtiments et logements - registre foncier, registre des habitants. Le conseil fédéral définit quels registres font autorité et comment les identifiants sont attribués. Le numéro d'identification des entreprises (UID) est un bon exemple: un identifiant unique, stable et public, qui sert de clé étrangère dans de nombreux systèmes cantonaux.

D'un point de vue data engineering, ces registres posent les mêmes problèmes qu'un data warehouse fédéré: doublons, synchronisation, gestion des changements d'état et qualité des données. L'infrastructure sedex transporte des messages asynchrones entre administrations, un peu comme un bus Kafka avec accusés de réception et files de retry. Dans plusieurs projets, nous avons remplacé des exports CSV nocturnes par des flux événementiels via sedex, ce qui a réduit les erreurs de rapprochement de plusieurs heures à quelques minutes.

La prochaine étape logique serait d'exposer ces registres via des API REST ou gRPC avec des abonnements push. Article lié: ingérer des données administratives avec Kafka et Debezium. Le conseil fédéral a déjà encouragé le principe « once-only »: un citoyen ne devrait pas fournir deux fois la même donnée. Mais sans APIs de lecture transactionnelle, ce principe reste difficile à implémenter,

Cloud souverain et exigences de résidence des données

La stratégie cloud du conseil fédéral, adoptée en 2020, autorise l'usage du nuage public pour certaines charges, à condition de respecter des exigences strictes de sécurité et de localisation des données. Les informations sensibles doivent rester chiffrées, et les clés de chiffrement doivent être gérées dans un périmètre de confiance suisse. Cela rappelle les architectures de confidential computing et les HSM (Hardware Security Modules) utilisés dans le secteur bancaire.

Dans un déploiement de ce type, nous avons utilisé Terraform et HashiCorp Vault pour séparer les secrets du code, avec une politique de résidence des clés. Le principal défi n'est pas technique, mais contractuel: définir ce que signifie réellement « données en Suisse » lorsque le fournisseur de cloud est une multinationale. Le conseil fédéral impose des clauses d'audit, des plans de sortie et des garanties sur les sauvegardes.

Pour les équipes d'ingénierie, cela se traduit par des pipelines GitOps où chaque déploiement est traçable. Tutoriel: déployer un cluster Kubernetes avec OpenTofu sur infrastructure suisse. La souveraineté numérique n'est pas un slogan: c'est une série de contrôles techniques, de politiques IAM et de décisions d'hébergement qu'il faut documenter.

Cybersécurité et gestion des incidents dans la Confédération

Le conseil fédéral a renforcé le Centre national pour la cybersécurité (NCSC) afin de coordonner la réponse aux incidents critiques. Pour un ingénieur SRE, cette structure fonctionne comme un SOC fédéré: les cantons signalent les événements, le NCSC diffuse des indicateurs de compromission et des playbooks de réponse. La loi impose des obligations de notification pour les opérateurs d'infrastructures critiques.

En pratique, la gestion des incidents repose sur des runbooks, des canaux de communication hors bande et des exercices de simulation. Des frameworks comme MITRE ATT&CK et des taxonomies d'incidents partagées permettent de comparer les menaces entre administrations. Mais la maturité varie fortement d'un canton à l'autre. Certains ont des équipes de détection temps réel, d'autres externalisent encore la surveillance de leurs journaux.

Le conseil fédéral pousse vers une approche basée sur les risques, avec des audits réguliers et des indicateurs de couverture. Pour les éditeurs de logiciels qui vendent aux administrations, cela signifie qu'un produit doit pouvoir générer des logs structurés, s'intégrer à un SIEM et supporter des politiques de rétention légales. La conformité n'est pas une option marketing.

API gouvernementales: contrats d'interface et gestion de version

L'administration fédérale publie de plus en plus d'interfaces de programmation. Le conseil fédéral encourage la réutilisation des données publiques et des services, ce qui implique de traiter les API comme des produits à part entière. Un endpoint gouvernemental ne peut pas casser du jour au lendemain: des services critiques, des applications cantonales et des entreprises privées en dépendent.

La gestion de version est donc essentielle. Les bonnes pratiques incluent l'utilisation d'OpenAPI pour décrire les contrats, la mise en place de tests de non-régression et la publication de journaux de modifications. Dans une API de registre que nous avons auditée, l'absence de versioning explicite avait mené à un changement de type d'un champ booléen en chaîne, cassant silencieusement trois consommateurs. Le correctif a été simple, mais la détection a pris des semaines.

Pour éviter cela, les équipes devraient adopter des politiques de dépréciation, des fenêtres de compatibilité et des tests contractuels avec Pact ou Dredd. Bonnes pratiques: versionner une API publique sans casser vos clients. Le conseil fédéral pourrait imposer ces exigences dans les appels d'offres publics.

Observabilité et SRE dans les services publics critiques

Les services publics critiques, comme l'alerte à la population via Alertswiss, exigent une disponibilité élevée. Le conseil fédéral supervise ces plateformes, mais l'exploitation est déléguée à des offices fédéraux. Pour un ingénieur SRE, cela pose des questions de SLO, de capacité et de résilience face aux pics d'utilisation. Une alerte météo majeure peut multiplier le trafic par dix en quelques minutes.

Les outils modernes - Prometheus, Grafana, OpenTelemetry - sont désormais présents dans plusieurs administrations suisses. La collecte de métriques, de traces et de logs permet de détecter les anomalies avant que les utilisateurs ne les signalent. Mais l'observabilité ne sert à rien sans une culture du postmortem sans blâme. Dans un incident récent sur une API fédérale, le problème venait d'une limitation de connexions à la base de données, pas d'une erreur humaine.

Le conseil fédéral gagnerait à publier des rapports de disponibilité agrégés et des rétrospectives publiques. Cela renforcerait la confiance et fournirait des données précieuses aux fournisseurs. La transparence opérationnelle est un levier d'amélioration continue.

Automatisation de la conformité réglementaire dans l'administration fédérale

La conformité dans le secteur public suisse est souvent perçue comme une charge documentaire. Mais elle peut être automatisée. Le conseil fédéral a adopté des principes de minimisation des données et de séparation des pouvoirs qui peuvent être traduits en politiques exécutables. Des outils comme Open Policy Agent (OPA) et son langage Rego permettent d'encoder des règles d'accès fines, comme « un employé communal ne peut lire que les données des habitants de sa commune ».

Dans un projet de conformité pour un système d'aide sociale, nous avons codé ces règles avec OPA et les avons intégrées dans le pipeline CI/CD. Chaque changement de politique était testé comme du code, avec des cas limites et des revues de pull request. L'effet a été double: moins d'erreurs d'autorisation et une traçabilité complète des décisions.

Cette approche de compliance as code est encore rare dans les administrations, mais elle correspond à la direction prise par le conseil fédéral vers une administration numérique réactive. Comprendre Open Policy Agent pour l'autorisation fine dans vos APIs. Les audits deviennent alors une simple vérification de l'état du dépôt, pas une chasse aux documents.

Enseignements pour les ingénieurs du secteur privé

L'expérience suisse montre qu'une architecture fédérée peut rester cohérente si l'on investit dans les contrats d'interface, la gestion de version et la gouvernance des données. Le conseil fédéral ne résout pas tout, mais il fournit un cadre qui évite les pires dérives. Les entreprises qui construisent des plateformes multi-équipes peuvent s'en inspirer: moins de contrôle centralisé, plus de standards partagés.

Pour un ingénieur, trois pratiques sont transposables: traiter les schémas de données comme des dépendances versionnées, imposer des SLO pour les services partagés et automatiser les politiques de conformité. Ce ne sont pas des idées révolutionnaires, mais elles sont trop souvent négligées au profit de la vélocité. La robustesse d'un système se joue précisément dans ces détails.

FAQ: conseil fédéral et transformation numérique

Le conseil fédéral développe-t-il lui-même des logiciels?

Non, le conseil fédéral définit les orientations, les budgets et les normes. Le développement est réalisé par des offices fédéraux, des cantons ou des prestataires externes. Son rôle technique principal est la gouvernance des plateformes et des standards,

Qu'est-ce que le standard eCH

Les standards eCH sont des spécifications d'interopérabilité pour l'administration suisse. Ils couvrent des modèles de données, des formats d'échange et des règles de sécurité. Ils sont publiés par l'association eCH et utilisés par la Confédération, les cantons et les communes.

Pourquoi la première loi sur l'e-ID a-t-elle été rejetée?

Le projet rejeté en 2021 confiait la vérification d'identité à des prestataires privés. Les opposants estimaient que cela créait un risque de contrôle des données personnelles. Le nouveau projet du conseil fédéral prévoit une émission étatique de l'identité électronique,

Qu'est-ce que sedex

Sedex est l'infrastructure d'échange sécurisé de données entre administrations suisses. Elle fonctionne de manière asynchrone, avec des accusés de réception et des files d'attente, comparable à un bus de messages comme Kafka mais adapté aux contraintes légales.

Le cloud public est-il autorisé pour les données de l'administration suisse,

Oui, sous conditionsLa stratégie cloud du conseil fédéral autorise le nuage public pour certaines charges, à condition que les données sensibles soient chiffrées, que les clés soient gérées en Suisse et que des audits soient possibles.

Conclusion: tirer parti de l'architecture fédérale

Le conseil fédéral est souvent perçu comme un organe politique, mais son influence technique est considérable. Il fixe les standards, arbitre les choix d'infrastructure et impose des exigences de sécurité qui structurent l'ensemble de l'administration suisse. Pour les ingénieurs, c'est un cas d'école de gouvernance de plateforme à grande échelle.

Que vous construisiez une API publique, un système d'identité ou une plateforme de données, les leçons sont les mêmes: des contrats explicites, une gestion de version rigoureuse et une conformité automatisée. Si vous travaillez sur des projets touchant l'administration suisse, intégrez ces contraintes dès la conception, pas après coup.

Si cet article vous a aidé à comprendre les coulisses techniques du conseil fédéral, partagez-le avec votre équipe. Et si vous avez des retours d'expérience sur les standards eCH ou sedex, laissez un commentaire ci-dessous.

What do you think?

Le modèle fédéral suisse de gouvernance numérique est-il transposable à une grande entreprise, ou la lenteur de décision du conseil fédéral rend-elle ce modèle obsolète face à des géants du cloud?

Faut-il imposer des standards d'API et des SLO par la loi, ou est-ce aux administrations de les adopter volontairement pour rester agiles?

La future e-ID suisse devrait-elle s'appuyer sur des portefeuilles numériques décentralisés, ou une architecture centralisée reste-t-elle plus sûre pour un État?