L'AQAP 2110 est la Publication Alliée d'Assurance Qualité régissant les exigences du système de management de la qualité pour la conception, le développement et la production de logiciels dans le cadre de contrats de défense. Alors que l'ISO 9001 est la norme de qualité de base reconnue dans tous les secteurs, l'AQAP 2110 va plus loin — elle est spécifiquement rédigée pour le contexte de l'acquisition de défense, imposant des exigences supplémentaires qui reflètent les exigences uniques des programmes logiciels militaires : surveillance de l'assurance qualité gouvernementale (AQG), planification formelle du développement logiciel et gestion rigoureuse de la configuration.

Pour un fournisseur de logiciels cherchant à travailler sur des contrats émis par des nations membres, comprendre ce qu'exige l'AQAP 2110 et en quoi elle diffère de l'ISO 9001 en pratique est une préparation indispensable.

Ce qu'est l'AQAP 2110 et en quoi elle diffère de l'ISO 9001

L'AQAP 2110 est basée sur l'ISO 9001 et en incorpore toutes les exigences. Les fournisseurs certifiés AQAP 2110 satisfont implicitement à l'ISO 9001. Cependant, l'AQAP 2110 ajoute une couche d'exigences spécifiques à la défense que l'ISO 9001 ne contient pas.

L'ajout le plus significatif est l'Assurance Qualité Gouvernementale (AQG). Conformément à l'AQAP 2110, l'autorité contractante conserve le droit de mener des audits de surveillance du système de management de la qualité du fournisseur pendant l'exécution du contrat. Un représentant gouvernemental de l'assurance qualité (RGAQ) peut visiter les sites du fournisseur, examiner les artefacts de développement, assister aux tests et vérifier que les processus de développement logiciel contractuels sont effectivement respectés.

L'AQAP 2110 exige également que les fournisseurs produisent un Plan de Développement Logiciel (PDL) — un document formel définissant comment le fournisseur gérera le processus de développement logiciel pour le contrat spécifique. Le PDL est soumis à l'approbation du client avant le début du développement.

Exigences clés : PDL, GCL, vérification et validation, revues

Plan de Développement Logiciel (PDL). Le PDL est le document de planification spécifique au contrat qui lie les capacités générales du SMQ du fournisseur au programme spécifique. Il doit identifier les éléments logiciels dans le périmètre, la méthodologie de développement à utiliser, les environnements de développement et de test, l'approche de gestion de configuration, le registre des risques et les stratégies d'atténuation, ainsi que le calendrier et les jalons des activités qualité.

Gestion de Configuration Logicielle (GCL). L'AQAP 2110 exige un système GCL formel assurant une traçabilité complète des exigences à travers la conception, l'implémentation et les tests jusqu'au logiciel livré. L'identification des éléments de configuration doit couvrir le code source, les scripts de build, les suites de tests, la documentation et les composants tiers.

Vérification et Validation (V&V). L'AQAP 2110 distingue la vérification (confirmation que le logiciel implémente correctement sa spécification) et la validation (confirmation que la spécification capture correctement les besoins du client). Les deux doivent être planifiées dans le PDL et exécutées avec des preuves documentées.

Revues formelles. La norme exige des revues formelles à des étapes définies du cycle de vie logiciel : Revue des Exigences Logicielles (REL), Revue Préliminaire de Conception (RPC), Revue Critique de Conception (RCC) et Revue de Préparation aux Tests (RPT). Chaque revue a des critères d'entrée, un ordre du jour, des participants et des critères de sortie définis. Le client ou le RGAQ est généralement invité en tant qu'observateur ou participant.

Impact pratique : L'exigence PDL est l'endroit où la plupart des fournisseurs sous-estiment l'effort requis. Un PDL conforme pour un programme non trivial fait généralement 50 à 150 pages, couvre l'ensemble du cycle de vie du développement et doit être convenu avec le client avant le début des travaux. Les fournisseurs qui traitent le PDL comme une formalité — produisant un document minimal avec les bons mots sans refléter les pratiques réelles — sont susceptibles de rencontrer des difficultés lors des audits AQG.

Comment l'AQAP 2110 affecte les processus SDLC

L'impact pratique de l'AQAP 2110 sur les processus de développement logiciel est substantiel. La norme n'interdit pas les méthodes agiles ou itératives — elle exige que la méthode utilisée soit documentée, planifiée et systématiquement suivie. Les fournisseurs utilisant des méthodes agiles doivent documenter comment leurs pratiques agiles satisfont aux exigences de l'AQAP 2110 en matière de planification, de contrôle de configuration et de V&V.

La gestion des modifications devient significativement plus rigoureuse. Les modifications aux artefacts de conception de référence nécessitent une demande de modification, une analyse d'impact, une approbation par l'autorité compétente (incluant potentiellement le client) et une mise à jour des éléments de configuration affectés. Les exigences de preuves de test signifient que les plans, procédures, résultats de tests et rapports d'anomalies doivent être maintenus comme des enregistrements formels.

Processus de certification : NSPA et organismes nationaux de certification

La certification AQAP 2110 pour des contrats individuels est généralement gérée différemment de la certification ISO 9001. Plutôt qu'une certification globale unique, la conformité AQAP est généralement évaluée au niveau du contrat, avec la surveillance AQG effectuée par l'autorité nationale de la nation contractante.

L'Agence OTAN de Soutien et d'Acquisition (NSPA) fournit un soutien lié à l'AQAP et peut conduire l'AQG au nom des nations membres pour certaines catégories de contrats. En France, la DGA (Direction Générale de l'Armement) conduit la surveillance de l'assurance qualité pour les contrats dans sa juridiction. Les fournisseurs cherchant à démontrer la conformité AQAP 2110 poursuivent généralement l'une des deux voies : conformité spécifique au contrat ou certification par tierce partie.