L’Inde a acheté le Rafale. La France a gardé les mots de passe.

L’Inde chercherait apparemment à obtenir un plus grand accès au logiciel du système de mission du Rafale afin de pouvoir intégrer ses propres missiles. La France conserve le contrôle afin que l’Inde soit contrainte d’acheter des munitions françaises.

Ce n’est pas une question de sécurité, c’est une question commerciale.

La France affirme qu’elle considère le code et les interfaces les plus sensibles à un niveau supérieur à celui de la cellule. L’Inde dit : « bonjour, j’ai acheté les avions, logiciel compris. »

Aujourd’hui, le logiciel détermine la manière dont les armes, les capteurs et les systèmes de guerre électronique sont intégrés.

Un pays peut posséder et faire voler l’appareil tout en ayant encore besoin de l’autorisation d’un autre pour accéder au logiciel. Au moment de mettre sous presse, l’affaire faisait toujours l’objet de négociations.

Mais la négociation révèle la véritable clause de souveraineté : qui contrôle la prochaine modification après la vente de l’appareil ?

Un fait d’achat se cache derrière l’annonce publique : le contrôle du matériel est traité comme le contrôle de la capacité.

Mais ce qui compte réellement, c’est le code source, les clés de chiffrement, les données de mission, l’accès au cloud, les serveurs de mise à jour, le geofencing et les droits d’intégration propriétaires. C’est là le point de contrôle caché derrière le titre disant : « L’Inde a acheté le Rafale » et la question qui suit : « L’a-t-elle vraiment fait ? »

Pour l’Inde, ce n’était pas seulement une question comptable. Pour l’Inde, le problème était que la France, ou plus précisément Dassault, pouvait désactiver, réduire ou dégrader la capacité de ces chasseurs à réaction avancés par logiciel, sans déplacer le moindre bien matériel.

Dans ce cas, le contrat pourrait rester en vigueur, et la relation diplomatique pourrait rester cordiale, mais l’effet militaire n’en serait pas moins un éléphant blanc, un achat de plusieurs milliards de dollars aussi mort qu’un dodo.

Quelle est la leçon pour vous ?

Commencez par simuler l’échec dans un exercice sur table. Mettez-vous à la place de l’Inde. Supposez que la partie qui contrôle décide de désactiver, de restreindre ou de dégrader la capacité par le logiciel, ce qu’elle peut faire, à distance, depuis la France.

Qui s’en aperçoit en premier ? Qui a l’autorité pour activer l’alternative ? Combien de jours de stocks utilisables restent-ils ? Si les réponses exigent un nouveau budget et un nouveau contrat, vous n’avez pas de plan B.

Tandis que votre équipe technique testera la performance de mission, votre équipe commerciale devrait tester tout aussi rigoureusement la souveraineté.

Une géographie, un type de cible ou un mode sont-ils restreints dans le code ? Que se passe-t-il lorsque l’accès au cloud ou un abonnement prend fin ? Disposez-vous d’un code source exploitable, ou seulement d’une promesse d’entiercement assortie de conditions ?

Enfin, demandez-vous ce qui se passe sous pression : le système peut-il fonctionner lorsqu’il est déconnecté du fournisseur ? Qui contrôle les données de mission, les clés de chiffrement et les mises à jour logicielles ? Vos ingénieurs peuvent-ils intégrer une nouvelle arme ou un nouveau capteur ?

Avez-vous une solution de repli ? Si c’est une solution de repli qui n’a jamais été financée, intégrée ni exercée, ce n’est pas un plan. C’est seulement un optimisme probablement mal placé.

Vous devriez viser un meilleur contrat et tester le système dans un environnement national totalement déconnecté, prendre le contrôle des clés, des données de mission et négocier les droits d’intégration avant de signer le contrat de la plateforme. L’objectif n’est pas d’éliminer toute dépendance. Il s’agit d’empêcher qu’une dépendance invisible ne devienne une urgence nationale.

Évaluez cette exposition honnêtement.

Une offre moins chère avec un seul point d’accès non maîtrisé peut être plus coûteuse qu’une offre plus élevée qui vous donne tout le contrôle.

Bien sûr, vos équipes d’acquisition savent peut-être bien comparer les prix d’achat. Mais elles sont probablement moins constantes lorsqu’il s’agit d’évaluer le coût d’une flotte clouée au sol, d’un stock de munitions vide ou d’une capacité livrée après que le besoin de défense a disparu. Le fait mis en avant, « l’Inde a acheté le Rafale », devrait porter dans son texte cette exposition : « le matériel, pas le logiciel ».

Aucun acheteur sérieux n’a besoin de chaque ligne de code source. Mais tout acheteur sérieux doit disposer d’un contrôle sur les fonctions, les données, les clés et les droits d’intégration qui déterminent si le système peut réellement accomplir sa mission. Cette distinction compte ici : la France a gardé les mots de passe.

Le test final pour l’Inde est simple : que reste-t-il utilisable lorsque le réseau étranger, le serveur de mise à jour, le compte cloud et l’équipe d’intégration ne sont pas disponibles ? Si la réponse commence par « à condition que quelqu’un d’autre l’accepte », alors cette condition doit figurer sur la première page de la décision d’achat, et non dans une annexe que personne ne lit.

L’équipement peut rester entre vos mains tandis que ses fonctions utiles disparaissent derrière une connexion, une décision de serveur ou une ligne de code.

Le coupe-circuit n’a pas besoin d’être un bouton rouge. Il peut s’agir d’un identifiant expiré. C’est la question pratique que chacun devrait se poser derrière le titre : « L’Inde a acheté le Rafale ».