La conformité des logiciels gouvernementaux ne se limite pas à réussir une revue finale avant le lancement : elle commence par la manière dont le code est écrit, dont les dépendances sont gérées et dont les décisions sont documentées. Un article publié sur le blog de JetBrains, dans le contexte de la plateforme Qodana, présente cinq axes pratiques que les équipes de développement logiciel du secteur public peuvent utiliser pour réduire les risques de non-conformité, les exigences légales variant d’un pays à l’autre.
Cette question revêt une importance supplémentaire, car les systèmes gouvernementaux traitent de grandes quantités de données personnelles et sensibles. L’article cite le rapport IBM Cost of a Data Breach Report 2026, selon lequel le coût moyen mondial d’une violation de données s’est élevé à 4,99 millions de dollars. Il mentionne également un rapport du Ponemon Institute et de Globalscape, qui a estimé que le coût de la non-conformité était 2,71 fois supérieur à celui de la conformité. Ces chiffres proviennent des rapports sur lesquels s’appuie la source et ne constituent pas une estimation indépendante de JetBrains.
1. Sécurité et protection des données
Les risques commencent par des erreurs courantes, telles que le stockage des identifiants dans le code, une validation insuffisante des entrées et des sorties, ou l’utilisation d’algorithmes de chiffrement anciens et faibles. Cela peut entraîner la divulgation d’informations personnelles ou compromettre les contrôles de référentiels de sécurité tels que la norme ISO/IEC 27001, mettant en péril la certification et la réputation de l’organisation.
Les règles diffèrent selon la juridiction. Les organismes publics des pays de l’Union européenne sont soumis au règlement GDPR, tandis que les administrations centrales du Royaume-Uni doivent respecter notamment le UK GDPR, le Data Protection Act 2018 et les normes du National Audit Office. Aux États-Unis, des cadres tels que le Federal Acquisition Regulation, le Defense Federal Acquisition Regulation Supplement et FedRAMP s’appliquent.
En pratique, l’article recommande d’intégrer la protection de la vie privée et les mesures de défense au cycle de vie du développement logiciel dès le début, sans les reporter aux tests ou à la phase précédant le déploiement. Les mesures citées comprennent le stockage sécurisé des identifiants, la gestion claire du consentement des utilisateurs, la réalisation de tests d’intrusion avant le lancement et la poursuite des tests automatisés. Les dépendances externes devraient également être traitées comme des risques actifs, et non comme des composants neutres.
2. Contrats, achats et dépendances open source
Les logiciels qui gèrent les achats publics ou les accords avec les fournisseurs peuvent entraîner des problèmes contractuels, tels que le non-respect des niveaux de service ou des critères d’acceptation de la livraison. La présence d’une clé API secrète dans une branche de développement, en l’absence de contrôle SAST, peut également permettre la transmission d’un code qui ne satisfait pas aux conditions de livraison.
Les dépendances open source ajoutent une autre dimension juridique et technique, car leurs licences peuvent contenir des clauses telles que le copyleft ou des restrictions d’utilisation commerciale, susceptibles d’entrer en conflit avec les règles d’achat ou d’ouvrir des litiges concernant la propriété intellectuelle. L’article propose donc d’effectuer un contrôle automatisé des licences au niveau des dépendances, ainsi que de mettre en place des portes de qualité au sein de CI/CD afin d’empêcher le code non conforme de passer à l’étape de livraison.
3. Éléments probants auditables et responsabilité
Lors des audits, il ne suffit pas d’affirmer que les contrôles existent : les contrôles dépourvus d’éléments probants peuvent être considérés comme non démontrés. Selon l’article, la dépendance aux approbations manuelles et aux résultats incohérents entre les équipes d’assurance qualité augmente la probabilité d’un échec de l’audit et accroît les risques de dette technique.
La solution pratique proposée consiste à créer un registre numérique reliant les tests, la traçabilité et les résultats des contrôles aux étapes du cycle de développement. Cela contribue à produire des rapports d’audit automatisés et à fournir des éléments objectifs lors de l’examen de contrôles tels que les directives du NIST pour les systèmes fédéraux aux États-Unis, ou les exigences de la norme ISO/IEC 27001 et les normes du National Audit Office au Royaume-Uni.
4. Continuité et assistance à long terme
La panne d’un système gouvernemental peut entraîner l’interruption de services essentiels aux citoyens. La priorité ne devrait donc pas se limiter à une réparation rapide qui accumulerait des problèmes futurs. Les composants open source qui ne sont plus pris en charge peuvent empêcher l’application des correctifs, tandis que le transfert du système entre différents prestataires ou équipes devient plus risqué lorsque les vulnérabilités et le contexte des décisions ne sont pas documentés.
Les pratiques proposées comprennent le suivi de l’actualité des dépendances, l’utilisation de la dernière version stable ou de la version corrective disponible, la réduction du nombre de dépendances externes, la mise en œuvre de tests unitaires et d’intégration, ainsi que l’utilisation de l’analyse statique pour détecter rapidement les erreurs de code. Ces pratiques sont également liées aux exigences de continuité des activités, notamment à la norme ISO 22301.
5. Gouvernance de l’infrastructure et des politiques
Les outils de développement et les services cloud doivent être conformes aux référentiels de sécurité et aux politiques informatiques du gouvernement. L’article cite, par exemple, la politique Government Cloud First au Royaume-Uni, ainsi que les restrictions que les organismes publics peuvent imposer à l’utilisation de services SaaS ou de dépendances cloud externes, en particulier lorsqu’ils traitent des données sensibles ou sont soumis à des exigences FedRAMP.
Sur le plan opérationnel, la perte des connaissances institutionnelles représente un risque pour les systèmes ayant une longue durée de vie. La documentation du contexte des décisions, des solutions de contournement et de leurs justifications aide les nouvelles équipes à assurer la maintenance de l’infrastructure. Les outils hébergés localement ou isolés des réseaux externes peuvent également constituer une option adaptée lorsque la politique interdit de dépendre d’un cloud externe.
Qu’est-ce qui change en pratique ?
L’idée essentielle n’est pas d’acheter un outil particulier, mais de transformer la conformité en contrôles continus au sein de l’environnement de développement : contrôles de sécurité et de licences, détection des secrets, suivi des dépendances, tests automatisés et politiques exécutables et documentables dans CI/CD. Cette approche réduit la dépendance à une revue manuelle tardive, mais elle ne supprime pas la nécessité d’interpréter les exigences légales et de définir les responsabilités humaines. L’article ne démontre pas non plus que ces mesures garantissent une conformité totale dans chaque pays : il indique explicitement que les règles varient selon le lieu et les politiques appliquées. Dans ce contexte, Qodana est présentée comme un outil pouvant être intégré aux environnements de développement et aux pipelines d’intégration, un aspect promotionnel qui doit être distingué des principes généraux applicables avec différents outils.