Découpage du travail traçable
Chaque tâche d'implémentation est liée à une exigence spécifique ou à un critère d'acceptation — et non à une description de fonctionnalité vaguement liée.
Développement & Intégration · Étape 04 · Comment nous travaillons
Une spécification devient un logiciel.
La conception de la solution produit une spécification testée et des critères d'acceptation définis. Cette étape transforme cette spécification en logiciel opérationnel et vérifié — intégré aux systèmes avec lesquels il doit fonctionner, et validé par rapport aux critères définis avant le début du développement.
Ici, le développement n'est pas de l'interprétation. Chaque décision d'implémentation se rattache à une spécification produite durant la conception — et non à ce que le développeur supposait probablement être l'intention.
Pas cette question
"Le code s'exécute-t-il ?"
Plutôt cette question
"Le système construit satisfait‑il aux critères d'acceptation définis avant le démarrage — dans de réelles conditions d'intégration, et pas seulement isolément ?"
Implémentation · Vérification · Intégration · Traçabilité · Discipline de livraison
Pourquoi le développement suit la conception
Rien ici n'est laissé au hasard.
Chaque apport à cette étape a été produit lors de la conception de la solution : le document de spécification de la solution, le rapport d'évaluation du prototype et les critères d'acceptation & le plan de test. Développer à partir d'une spécification non testée reviendrait simplement à réintroduire dans le code en production le risque que le prototypage était censé éliminer.
Spécification de la solution + Critères d'acceptation → Implémentation vérifiée
Pourquoi la discipline de livraison est importante
La rapidité et la stabilité sont mesurées ensemble, pas l'une au détriment de l'autre.
La performance de livraison logicielle ne se résume pas à la vitesse d'écriture du code par une équipe. Des recherches de Forsgren, Humble et Kim — publiées dans Accelerate: The Science of Lean Software and DevOps (2018), fondées sur les recherches pluriannuelles du programme DevOps Research and Assessment (DORA) auprès de milliers d'organisations — ont identifié deux catégories de performance d'ingénierie qui doivent être mesurées conjointement : le débit et la stabilité.
Délai
Temps nécessaire pour qu'un changement validé passe du commit à un état déployable.
Forsgren, Humble & Kim, Accelerate (2018) ; DORA, State of DevOps research.
Taux d'échec des changements
Le pourcentage de changements qui introduisent un défaut nécessitant une correction.
Forsgren, Humble & Kim, Accelerate (2018) ; DORA, State of DevOps research.
Une équipe qui livre rapidement mais qui casse souvent les choses n'est pas performante selon ces recherches — pas plus qu'une équipe qui livre en toute sécurité mais trop lentement pour avoir de l'impact. OpenQCore prend en compte les deux dimensions à cette étape, plutôt que d'optimiser uniquement la vélocité.
De la spécification à l'implémentation
Chaque élément de travail se rattache à une exigence.
Le travail d'implémentation est décomposé directement à partir de la Spécification de la Solution et des Critères d'Acceptation — pas à partir d'une compréhension générale de ce que le design "visait."
Définition de Done
Une tâche n'est pas terminée lorsque le code est écrit. Elle est terminée lorsqu'elle satisfait le critère d'acceptation qui lui est lié, vérifié en test.
Contrôle de la dérive de la spécification
Lorsque l'implémentation révèle une lacune ou une ambiguïté dans la spécification, celle-ci est mise à jour et relue — et non réinterprétée en silence par la personne qui écrit le code ce jour-là.
Vérification pilotée par les tests
La vérification a lieu à tous les niveaux, pas seulement à la fin.
OpenQCore structure la vérification selon la pyramide des tests — un cadre largement utilisé, popularisé par Mike Cohn, visant à équilibrer la couverture de tests entre les couches d'un système plutôt que de la concentrer dans des tests de bout en bout lents et coûteux.
Tests unitaires
Vérification rapide et isolée des composants individuels par rapport à leur comportement spécifié — y compris leur comportement face à des entrées invalides.
Tests d'intégration
Vérification que les composants interagissent correctement conformément aux contrats de données définis lors de la conception de la solution.
Tests de bout en bout
Vérification des workflows complets par rapport aux critères d'acceptation définis avant le début du développement — la couche la plus restreinte et la plus coûteuse, réservée à ce qui l'exige réellement.
L'objectif n'est pas d'augmenter le nombre de tests. C'est d'avoir la confiance que les critères d'acceptation sont réellement satisfaits, au niveau le moins coûteux capable de le prouver.
Intégration et tests de contrat
Un contrat d'API n'est réel que s'il est testé, pas seulement documenté.
Les contrats de données et d'API spécifiés lors de la conception de la solution ne sont pas considérés comme de la documentation à suivre de manière informelle. OpenQCore applique le contract testing piloté par le consommateur — une approche formalisée par des outils tels que Pact — où chaque point d'intégration est vérifié par rapport à un contrat exécutable que les deux parties de l'intégration doivent satisfaire.
Ceci est particulièrement important pour les systèmes devant se connecter à une infrastructure existante : un contrat vérifié uniquement par revue manuelle peut se désynchroniser silencieusement au fur et à mesure que l'une ou l'autre partie évolue. Un contrat testé automatiquement ne le peut pas.
Revue de code et vérification statique
Un second relecteur repère ce que l'auteur ne voit pas.
Des recherches largement citées sur la revue de code par les pairs — y compris l'étude menée chez Cisco Systems et popularisée dans Best Kept Secrets of Peer Code Review de Cohen et al. — ont montré que l'efficacité de la revue dépend fortement du rythme et de l'étendue : des revues plus petites et plus fréquentes, effectuées sans pression temporelle, détectent sensiblement plus de défauts que de grandes revues effectuées rapidement.
OpenQCore applique une revue de code structurée parallèlement à une analyse statique automatisée — style, complexité et détection de vulnérabilités connues — comme couche de vérification permanente, et non comme un passage de courtoisie optionnel avant la fusion.
Pipeline d'intégration continue
Chaque changement est vérifié de la même manière, automatiquement.
Commit → Compilation automatisée → Tests unitaires & d'intégration → Analyse statique & de sécurité → Vérification des contrats → Prêt pour le déploiement.
La vérification manuelle et incohérente n'est pas évolutive et ne donne pas un signal fiable sur la sécurité réelle d'une modification à publier — une détermination prise à l'étape suivante, Déploiement & Mise en service. Ce que garantit cette étape, c'est qu'une modification atteignant cette porte a déjà été vérifiée selon la même norme automatisée que toutes les modifications précédentes.
Pratiques de développement sécurisées
La sécurité est vérifiée pendant le développement, pas auditée après.
Les pratiques de développement d'OpenQCore s'alignent sur la structure décrite dans le Secure Software Development Framework (SP 800-218) du NIST — organisant les activités de sécurité autour de la préparation de l'organisation, la protection des logiciels, la production de logiciels bien sécurisés, et la réponse aux vulnérabilités.
Analyse des dépendances et des vulnérabilités
Analyse automatisée des dépendances tierces pour détecter les vulnérabilités connues dans le cadre du pipeline standard, et non un audit manuel périodique.
Modélisation des menaces
Examen structuré des façons dont un composant pourrait être mal utilisé, informé par les modes de défaillance définis lors de la conception de la solution.
Implémentation du principe du moindre privilège
Les accès et portées d'autorisation sont implémentés au niveau le plus restreint qui satisfasse la spécification — et non au niveau le plus large par commodité.
La porte de vérification d'intégration
Un build n'est pas prêt simplement parce qu'il compile.
Chaque modification atteint un point de vérification défini avant d'être considérée pour le déploiement.
Prêt pour le déploiement
Tous les critères d'acceptation sont satisfaits, vérifiés par des tests automatisés, des contrôles de contrat et des analyses de sécurité.
Retour pour corrections
Les défauts spécifiques et identifiés doivent être résolus avant que cette modification puisse continuer.
Retour à la conception
L'implémentation a révélé que la spécification elle-même ne tient pas dans des conditions réelles — la bonne réponse est de réviser la spécification, et non de la contourner par du code.
Escalader le risque
Un risque de sécurité, de conformité ou d'architecture a été identifié et nécessite une décision au-delà de l'autorité de l'équipe de développement.
Un pipeline qui atteint toujours "prêt pour le déploiement" ne vérifie rien.
Ce que cette étape produit
Logiciel prêt pour la décision de déployer — pas encore déployé.
Selon la portée de l'intervention, cette étape produit :
Base de code vérifiée
Implémentation traçable jusqu'à la spécification, satisfaisant toutes les couches de vérification définies.
Rapport de couverture de tests
Résultats des tests unitaires, d'intégration et de bout en bout cartographiés sur les critères d'acceptation.
Suite de tests de contrat
Vérification exécutable de chaque point d'intégration défini lors de la conception de la solution.
Historique des revues de code
Historique documenté des revues et de la résolution des problèmes soulevés.
Résultats de l'analyse de sécurité
Résultats des analyses de dépendances, de vulnérabilités et statiques, ainsi que leur résolution.
Documentation du pipeline CI
Le pipeline de vérification automatisé appliqué à ce changement, et à chaque changement qui suit.
Du développement au déploiement et à la mise en service
Le logiciel vérifié n'est pas encore un logiciel en production.
Le développement et l'intégration produisent un logiciel vérifié par rapport à sa spécification — pas un logiciel qui a été déployé, surveillé ou démontré comme stable sous une charge réelle en production. L'étape suivante définit comment, quand et avec quelle sécurité ce logiciel atteint effectivement la production.
Spécification de la solution → Implémentation vérifiée → Déploiement et mise en service
Étape 05
Déploiement et mise en service
Mettre en production un logiciel vérifié de manière sûre, réfléchie, et avec une procédure définie de retour arrière.
Références de recherche et méthodologiques
Forsgren, N., Humble, J., & Kim, G. — Accelerate : la science des logiciels Lean et du DevOps (2018) ; Google Cloud, recherche DORA sur l'état du DevOps
Source des métriques de performance de livraison mentionnées ci‑dessus.
Cohn, M. — Réussir avec Agile (2009)
Source du concept de pyramide de tests mentionné dans la vérification dirigée par les tests ci‑dessus.
Cohen, J. et al. — Les meilleurs secrets de la revue de code par les pairs (SmartBear, basé sur des recherches chez Cisco Systems)
Source des conclusions sur l'efficacité des revues de code mentionnées ci‑dessus.
Pact / contrats pilotés par le consommateur
Une approche établie des contrats d'intégration exécutables et vérifiés automatiquement, mentionnée dans la section des tests d'intégration ci‑dessus.
NIST — Cadre de développement sécurisé de logiciels, SP 800-218
Source de la structure mentionnée dans les pratiques de développement sécurisé ci‑dessus.