Partout en Europe, une décision familière se profile dans les capitales les unes après les autres. Les gouvernements ont raison de conclure que les activités sensibles ne doivent pas dépendre d’applications de messagerie grand public et que les communications officielles doivent rester sous contrôle national. La France gère Tchap. L’Allemagne exploite BundesMessenger. La Belgique, la Pologne, le Luxembourg et d’autres pays ont lancé des équivalents nationaux, et l’OTAN en a développé un pour son propre personnel. La tendance est indéniable. La question plus épineuse est de savoir si la souveraineté s’exerce au mieux en détenant le code, ou en détenant les moyens de contrôle qui déterminent où le système fonctionne, qui détient les clés, quelle législation le régit et qui est responsable de sa sécurité.

BlackBerry Secure Communications aborde cette question en s'appuyant sur une longue expérience dans le domaine des communications sécurisées de niveau gouvernemental, notamment dans le cadre de déploiements où le contrôle national, l'exploitation sur le territoire national et la certification de sécurité sont des critères non négociables. La souveraineté doit être la norme. La question est de savoir si une plateforme développée en interne ou une technologie certifiée déployée selon des conditions nationales offre un contrôle plus solide à long terme — et ce qu'un pays doit mettre en œuvre pour préserver ce contrôle.

Développer ou déployer selon les conditions nationales

Les gouvernements disposent généralement de deux moyens pour exercer un contrôle souverain sur les communications officielles :

1. Ils peuvent développer ou créer une branche de leur propre plateforme et l'exploiter eux-mêmes ;

2. Ils peuvent déployer des logiciels commerciaux certifiés selon leurs propres conditions : sur une infrastructure nationale, les clés de chiffrement étant détenues exclusivement par l'État, approuvés par leur propre autorité nationale et exploités à l'intérieur de leurs propres frontières.

Ces deux voies peuvent permettre à un gouvernement d’exercer un contrôle. La différence ne réside pas dans l’objectif, mais dans le modèle opérationnel qu’un pays accepte d’adopter pour l’atteindre. Une plateforme développée en interne concentre au sein d’un programme national unique la responsabilité des correctifs, de la certification, des effectifs, de la résilience et du financement à long terme. Un modèle commercial certifié permet de préserver le contrôle national tout en s’appuyant sur l’expertise technique, la capacité de réponse aux vulnérabilités et l’expérience opérationnelle déjà acquises auprès d’une clientèle plus large.

Cette approche de développement séduit pour des raisons compréhensibles : elle apparaît comme l’expression la plus aboutie de l’indépendance ; les outils modernes permettent de mettre au point un prototype fonctionnel plus rapidement que jamais ; et une plateforme nationale peut être présentée comme un investissement dans les capacités nationales. Aucune de ces motivations n’est erronée. Mais elles ne décrivent que la phase de lancement. Le véritable défi réside dans ce que le pays devra financer, doter en personnel, certifier et défendre une fois la plateforme opérationnelle.

Ce à quoi un projet engage un pays

Presque aucun des messagers nationaux actuellement en service n’a été développé à partir de zéro. La plupart sont des dérivés d’une même base open source, adaptés puis maintenus par l’État depuis lors. Il s’agit d’un choix technique raisonnable. Cela signifie également que le gouvernement hérite de tout ce qui découle de cette base — et en devient propriétaire de manière permanente.

La mise en place d'une plateforme est un projet qui a un début et une fin. Assurer son fonctionnement en toute sécurité relève quant à lui d'une mission permanente des pouvoirs publics. Cela implique des correctifs continus, un fonctionnement 24 heures sur 24, des certifications régulières, une expertise interne en cryptographie et en sécurité, ainsi qu'une obligation de rendre des comptes au public en cas de problème.

Le coût de développement d’un système est souvent présenté comme un montant ponctuel. Le chiffre réel correspond au coût total de possession sur dix ans, dont la majeure partie est engagée après le lancement. Les mises à jour continues, le centre d’opérations de sécurité, les certifications récurrentes et les spécialistes qui les assurent coûtent à peu près le même prix, qu’ils soient au service d’un seul gouvernement ou de cinquante. Un fournisseur met en place cette capacité une seule fois et la répartit entre tous ses clients. Un gouvernement qui développe son propre système doit en supporter l’intégralité dans le cadre d’un seul budget national. 

La charge opérationnelle est identique sur les deux voies. La différence réside dans le fait de savoir si un seul budget national en supporte l'intégralité.

La menace a modifié les calculs

Il existe aujourd’hui un nouvel aspect que toute personne qui évalue la stratégie de développement devrait prendre en compte. À mesure que les outils automatisés réduisent le délai entre la divulgation publique d’une vulnérabilité et son exploitation, la question déterminante n’est plus de savoir si un gouvernement a les moyens de corriger la faille, mais s’il est capable de le faire avant que celle-ci ne soit utilisée à son encontre.

Au début de cette année, l’une de ces plateformes nationales a été piratée. Aucun chiffrement n’a été contourné et aucune faille du logiciel lui-même n’a été exploitée. Un seul compte utilisateur a été compromis par le biais d’une technique d’ingénierie sociale — et cela a suffi pour accéder aux salles publiques non chiffrées que l’architecture rend consultables par tout utilisateur authentifié. Le chiffrement a rempli son rôle. La faille semble provenir de l’architecture qui l’entoure : un modèle hérité d’une fondation open source et maintenu au sein d’un programme national unique.

La profondeur est un facteur déterminant, car la gestion des vulnérabilités repose sur la télémétrie, les renseignements sur les menaces, les capacités techniques, la visibilité sur la clientèle, ainsi que la rapidité des tests et des déploiements. Une petite équipe nationale qui doit attendre un correctif en amont sur lequel elle n’a aucun contrôle se trouve dans une situation de désavantage structurel dans une course qui se mesure désormais en heures. Une organisation qui gère les vulnérabilités pour une large base de clients est en mesure d’agir plus rapidement à mesure que la menace s’intensifie.

La résilience obéit à la même logique. La capacité à résister à des pics de charge, à des réseaux dégradés et à une infrastructure pouvant elle-même être la cible d’une attaque a fait ses preuves dans de nombreux déploiements, et n’est pas démontrée pour la première fois lors du premier incident national touchant la plateforme elle-même.

Lorsque l'exploitation survient quelques heures seulement après la divulgation, la responsabilité de la correction prime sur la paternité du code.

Bien plus qu'une simple application de messagerie

Il y a un autre aspect de la question qu’un fork d’application de messagerie ne prend pas en compte. Sécuriser la voix et la messagerie est un véritable travail, et un fork qui y parvient a accompli quelque chose de substantiel. Mais la sécurité des communications va bien au-delà de la simple messagerie. L’appareil sur lequel s’effectue la conversation doit également être protégé, sans quoi la sécurité de l’échange ne dépasse pas celle du terminal sur lequel il s’appuie. Lorsqu’un incident touche plusieurs agences qui ne partagent pas de chaîne de commandement commune, la réponse doit également être coordonnée entre elles. Chaque couche constitue une infrastructure distincte, avec sa propre certification et ses propres contraintes opérationnelles. Un fork assure la première couche. Un gouvernement qui souhaite disposer de toutes les capacités s’engage, en réalité, à mettre en place et à maintenir plusieurs plateformes.

La souveraineté, c'est le contrôle, pas la paternité

Derrière tout cela se cache une confusion qu’il convient de souligner. La souveraineté est parfois considérée comme une question de savoir qui a écrit le code, alors qu’il s’agit en réalité d’une question de contrôle : qui détient les clés, où le système fonctionne-t-il, quelle législation le régit et qui en est responsable ? Un gouvernement peut écrire chaque ligne de code tout en dépendant d’un fournisseur étranger en amont pour les correctifs de sécurité. Il peut également déployer des logiciels commerciaux tout en conservant le contrôle de tous les points stratégiques, à condition que l’architecture soit conçue à cet effet.

C’est cette distinction que tout gouvernement confronté à ce choix doit garder à l’esprit. L’objectif n’est pas la propriété intellectuelle en soi. L’objectif est de contrôler où le logiciel est exécuté, qui détient les clés, qui le certifie et l’exploite, et qui intervient lorsqu’il faut le défendre. La propriété intellectuelle peut être une voie vers ce contrôle, mais ce n’est qu’une voie parmi d’autres. Les ressources techniques, l’attention opérationnelle et le budget qu’exige chaque année une plateforme développée en interne sont limités. Ce qui est dépensé à cet effet ne peut l’être pour le reste d’une mission de sécurité nationale. Entre nations partageant les mêmes valeurs, la résilience est renforcée en s’appuyant les unes sur les autres lorsque cela s’avère judicieux, plutôt qu’en reconstruisant chacune de son côté les mêmes fondations.

Secusmart illustre parfaitement ce modèle dans la pratique. Il s’agit d’une entreprise allemande, conçue et exploitée au sein des structures allemandes et certifiée par l’autorité fédérale allemande. Son travail dans le domaine des communications gouvernementales sécurisées fait partie intégrante du paysage national depuis des années. Cela montre que la souveraineté ne signifie pas nécessairement de tout reconstruire soi-même, à tous les niveaux. Les gouvernements devraient exiger une souveraineté sans compromis, puis évaluer le coût total sur dix ans avant de décider quel modèle adopter.