2.10 Gestion de configuration logicielle

Vue d’ensemble et motivation

La gestion de configuration logicielle (SCM) est la discipline d’identifier les composants d’un système logiciel, de contrôler comment ils changent, d’enregistrer l’état de chaque changement, et de vérifier que ce que vous avez construit et livré correspond à ce que vous vouliez. Elle répond à une question qui semble simple mais devient difficile à l’échelle : qu’y a-t-il exactement dans cette publication, comment est-elle arrivée là, et qui l’a approuvée ? Le SWEBOK traite la SCM comme un domaine de connaissance fondamental pour une raison claire : chaque autre activité d’ingénierie a besoin d’une configuration stable et connue contre laquelle travailler.

Sur une grande équipe, la SCM est le tissu conjonctif qui garde des milliers de pièces mobiles cohérentes. Le code source, les bibliothèques, les images de conteneur, les définitions d’infrastructure, les données de configuration, la documentation, et les artefacts de test changent tous sur leurs propres horloges, et un système livré est une combinaison spécifique de versions spécifiques de tous ceux-ci. Sans gestion de configuration délibérée, cette combinaison est inconnue et ne peut pas être reproduite. Vous ne pouvez pas recréer une publication passée, tracer un défaut jusqu’au changement qui l’a causé, ou dire avec confiance ce qui fonctionne en production.

Les contextes d’entreprise et gouvernementaux élèvent les enjeux. Les programmes réglementés et du secteur public doivent montrer que les changements ont été autorisés, révisés, et enregistrés ; qu’une construction livrée se retrace aux exigences et à la source approuvées ; et que rien n’est entré dans le système de façon incontrôlée. Ici, la SCM est autant un système de preuve qu’un système d’ingénierie. Le contrôle de version (chapitre 2.6) gère l’historique source ; la SCM gouverne toute la configuration et le processus contrôlé par lequel elle change. Elle est étroitement liée à l’infrastructure comme code (chapitre 8.2), aux pipelines de livraison (chapitre 8.1), et à l’audit et l’assurance (chapitre 10.2).

Principes clés

Tout ce qui détermine le comportement du système est un élément de configuration contrôlé, pas seulement le code source.
Une référence est un point de référence connu et convenu ; les changements sont faits contre des références délibérément, pas au hasard.
Le changement est contrôlé et enregistré, pas empêché ; l’objectif est un changement autorisé et traçable.
La comptabilité de statut signifie que vous pouvez toujours répondre à ce qui est dans une configuration et quel est son historique de changement.
Les audits vérifient que le système construit et livré correspond à la configuration enregistrée et aux exigences approuvées.
La reproductibilité est non négociable : toute version publiée doit pouvoir être reconstruite depuis des entrées contrôlées.
Automatisez l’identification, l’enregistrement, et la vérification ; la comptabilité manuelle ne passe pas à l’échelle et ne survit pas à l’audit.

Recommandations

Définissez le processus SCM et assignez la propriété

Écrivez un plan SCM qui dit ce qui est sous contrôle de configuration, comment les éléments sont identifiés, comment les changements sont proposés et approuvés, et comment le statut est enregistré et audité. Assignez une propriété claire, comme un gestionnaire de configuration ou une équipe responsable, afin que la SCM ne soit pas le travail de tout le monde et donc de personne. Échelonnez le processus au risque : un petit outil interne a besoin d’un contrôle léger, tandis qu’un système critique pour la sécurité ou réglementé a besoin de comités et d’enregistrements formels. Ancrez le plan dans une norme reconnue comme IEEE 828 afin que les auditeurs et partenaires puissent le suivre.

Identifiez les éléments de configuration et établissez des références

Listez les éléments de configuration qui déterminent comment le système se comporte : source, dépendances, scripts de construction, images de conteneur, définitions d’infrastructure, données de configuration, schémas, et documents clés. Donnez à chacun un identifiant stable et un schéma de versionnement. Fixez des références à des points significatifs (une version publiée, un ensemble d’exigences approuvé, une construction certifiée) afin d’avoir une référence convenue contre laquelle changer et à laquelle revenir. Une référence est immuable : une fois que vous la déclarez, vous ne l’éditez pas. Vous la remplacez seulement par une nouvelle référence créée à travers le processus de changement.

Contrôlez le changement à travers un processus défini et des comités appropriés

Acheminez les changements aux éléments contrôlés à travers un chemin défini : proposition, évaluation d’impact, approbation, implémentation, et vérification. Pour les éléments à plus haut risque, utilisez un comité de contrôle des changements (CCB) qui pèse le coût, le risque, et le calendrier avant d’autoriser un changement. Dimensionnez correctement le comité : une porte automatisée légère pour les changements de code routiniers, et un CCB formel et transversal pour les changements qui touchent les références, les interfaces, ou le comportement réglementé. Enregistrez chaque décision et le raisonnement derrière elle, et connectez les décisions de configuration significatives aux registres de décision (chapitre 1.6) afin que le raisonnement survive.

Maintenez la comptabilité de statut de configuration

Gardez un enregistrement précis et interrogeable de chaque élément de configuration : sa version actuelle, à quelle référence il appartient, et les demandes de changement qui lui ont été appliquées. Cette comptabilité de statut est ce qui vous laisse répondre, à tout moment, à ce que contient une publication et comment elle est arrivée là. Générez l’enregistrement automatiquement depuis vos outils d’enregistrement (contrôle de version, pipeline, registre d’artefacts) au lieu de maintenir un tableur parallèle qui dérive de la réalité. Cet enregistrement est l’épine dorsale de la traçabilité de l’exigence au changement à la construction au déploiement.

Menez des audits de configuration

Vérifiez deux choses sur un calendrier régulier. Un audit de configuration fonctionnel confirme que la configuration fonctionne comme ses exigences le spécifient. Un audit de configuration physique confirme que les artefacts livrés correspondent à la configuration enregistrée : que la construction est venue de la source et des dépendances enregistrées et ne contient rien de non comptabilisé. Automatisez autant de cela que vous le pouvez : les constructions reproductibles, les sommes de contrôle d’artefacts, les nomenclatures logicielles (SBOM), et les attestations de provenance transforment l’audit d’une inspection manuelle en un contrôle continu.

Gérez les publications et la livraison comme des événements contrôlés

Traitez une publication comme une référence spécifique et identifiée livrée à travers un processus répétable. Versionnez vos publications explicitement, produisez un manifeste ou une nomenclature qui décrit exactement ce qui est inclus, et enregistrez la correspondance de la publication à la révision source au artefact déployé. Signez et calculez la somme de contrôle des artefacts publiés afin que quiconque en aval puisse vérifier leur intégrité. Liez la gestion de publication au pipeline de livraison (chapitre 8.1) afin que la promotion à travers les environnements soit elle-même contrôlée, enregistrée, et réversible.

Choisissez et intégrez l’outillage SCM

Appuyez-vous sur des outils qui automatisent l’identification, le contrôle, la comptabilité, et l’audit plutôt que de compter seulement sur la discipline : contrôle de version pour la source, registres d’artefacts et d’images pour les binaires, un pipeline immuable pour les constructions, infrastructure comme code pour les environnements, et outillage de dépendances et de SBOM pour la provenance. Connectez-les afin qu’un seul changement s’écoule de façon traçable du commit à la publication déployée. Ce que vous recherchez est une chaîne d’outils où l’enregistrement de configuration est un sous-produit de faire le travail, pas une corvée administrative séparée.

Compromis : avantages et inconvénients

Choix	Avantages	Inconvénients
Comités de contrôle des changements formels	Forte autorisation et piste d’audit ; risque pesé avant le changement	Débit plus lent ; frais généraux si appliqué aux changements routiniers
Portes automatisées légères	Flux rapide ; faibles frais généraux ; passe à l’échelle pour de nombreux changements	Plus faible pour les références à haut risque ; moins de délibération
Références immuables strictes	Points de référence reproductibles et auditables	Discipline et outillage requis ; friction si surutilisé
Comptabilité de statut automatisée	Enregistrement précis et toujours actuel ; prêt pour l’audit	Investissement d’outillage et d’intégration initial
Enregistrements de configuration manuels	Simple à démarrer ; aucun outillage nécessaire	Dérive de la réalité ; échoue à l’échelle et sous audit

Le compromis central est le contrôle contre le flux. Un contrôle de changement lourd donne une forte assurance mais ralentit la livraison. Un contrôle léger coule rapidement mais affaiblit la traçabilité. La réponse n’est pas d’en choisir un globalement ; c’est d’échelonner le contrôle par risque : automatiser les changements routiniers à travers des portes rapides, et réserver les comités formels et les références immuables pour les éléments où l’autorisation et l’auditabilité comptent réellement. Le deuxième compromis est l’investissement d’outillage initial contre le coût administratif continu et le risque d’audit. La comptabilité automatisée coûte plus cher à mettre en place et bien moins cher à vivre avec.

Questions à discuter avec votre équipe

Qu’est-ce qui appartient exactement à notre liste d’éléments de configuration, et qui possède la décision quand quelque chose de nouveau apparaît ? La SCM ne fonctionne que si la liste des éléments contrôlés correspond à l’ensemble des choses qui déterminent réellement le comportement, et sur un grand système cet ensemble est plus grand que la plupart des équipes ne le pensent : source, dépendances, scripts de construction, images de conteneur, définitions d’infrastructure, schémas, indicateurs de fonctionnalité, et les données de configuration qui changent silencieusement ce que le logiciel fait. Si personne ne possède la liste, elle devient obsolète, et l’élément qui vous a fait tomber en production s’avère être la seule chose que personne n’a pensé à contrôler. Apportez votre inventaire actuel à la réunion et chassez les éléments déterminant le comportement qui y manquent. Assignez un propriétaire responsable (un gestionnaire de configuration ou une équipe nommée) afin qu’ajouter un nouvel élément soit une décision délibérée, pas un accident, parce que la SCM qui est le travail de tout le monde n’est le travail de personne.
Pouvons-nous prouver qu’un artefact déployé vient de la source et du pipeline que nous pensons, et cette preuve survivrait-elle à une falsification ? La reproductibilité et la traçabilité sont tout le point de la SCM, et la version pointue de la question est si vous pouvez lier le binaire en cours d’exécution à un commit et une exécution de construction spécifiques avec des preuves, pas une affirmation. Dans un système réglementé ou à haute valeur, c’est aussi votre défense de chaîne d’approvisionnement : les attestations de provenance signées, les sommes de contrôle d’artefacts, et une nomenclature logicielle transforment « nous sommes assez sûrs » en quelque chose qu’un auditeur ou un intervenant d’incident peut vérifier. Apportez votre dernière publication et essayez de la retracer en arrière depuis l’artefact déployé jusqu’au changement approuvé. Si un saut est une affirmation manuelle plutôt qu’un lien enregistré et vérifiable, c’est là qu’un attaquant ou une erreur honnête peut glisser quelque chose sans être remarqué, et le fermer signifie câbler la signature et la provenance dans le pipeline afin que l’enregistrement soit un sous-produit de la livraison.
Quelqu’un est-il capable d’éditer une publication en place aujourd’hui, et qu’est-ce que cela ferait à notre capacité de lui faire confiance ? Une référence n’est utile que si elle est immuable : dès l’instant où « la publication » peut être éditée après coup, vous ne pouvez plus la reproduire ou compter dessus comme référence, et chaque audit en aval devient de l’archéologie. L’échec classique est une configuration éditée directement en production ou une étiquette silencieusement déplacée, ce qui est exactement le raccourci qui semble inoffensif et rend une publication impossible à reconstruire plus tard. Apportez la réponse honnête à la réunion : qui a l’accès pour changer une référence déployée sans passer par le processus de changement, et cela s’est-il produit ? La correction est de rendre les références réellement immuables et d’acheminer chaque changement à travers proposition, évaluation d’impact, approbation, et vérification, échelonnant la rigueur afin que les changements routiniers coulent à travers des portes automatisées rapides tandis que les changements de référence et réglementés vont à un comité.
Notre comptabilité de statut de configuration est-elle générée automatiquement depuis nos outils d’enregistrement, ou maintenue à la main, et à quel point a-t-elle dérivé de ce qui est réellement déployé ? La comptabilité de statut est l’enregistrement qui vous laisse répondre, à tout moment, à ce que contient une publication et comment elle est arrivée là, et sur un grand système, cet enregistrement n’est digne de confiance que s’il découle du travail plutôt que d’être tapé dans un tableur parallèle. La tentation concurrente est qu’un registre tenu à la main semble peu coûteux à démarrer et flexible, tandis que l’automatiser signifie intégrer le contrôle de version, le pipeline, et le registre d’artefacts afin que l’enregistrement devienne un sous-produit de la livraison. Apportez le registre sur lequel vous comptez aujourd’hui, choisissez trois publications récentes au hasard, et vérifiez si les versions, références, et demandes de changement appliquées enregistrées correspondent à ce que l’outillage dit avoir été livré. Pour une entreprise ou un programme gouvernemental, un enregistrement de statut qui diverge de la réalité n’est pas un problème de propreté, c’est une conclusion d’audit qui attend d’arriver, parce qu’un auditeur qui attrape une lacune arrête de faire confiance à tout le compte et vous demande de le reconstruire à la main.
Notre contrôle de changement est-il échelonné par risque, ou le même niveau de cérémonie gouverne-t-il chaque changement peu importe ce qu’il touche ? Le contrôle et le flux tirent l’un contre l’autre : un comité de contrôle des changements formel pèse le coût, le risque, et le calendrier avant d’autoriser un changement, mais appliquer cette cérémonie à un ajustement de code routinier ajoute juste du délai, tandis que pousser une référence partagée ou un flux de paiement réglementé à travers une porte automatisée rapide retire la délibération exactement là où vous en avez besoin. Les modes d’échec sont symétriques, une lourdeur uniforme que les gens apprennent à contourner, ou un laxisme uniforme qui laisse un changement à haut risque passer sans examen. Apportez un échantillon des changements du dernier trimestre triés par ce que chacun a touché, et vérifiez si la rigueur qu’il a reçue correspondait réellement à son risque. Dans un contexte réglementé ou du secteur public, nommez quelles classes d’éléments doivent atteindre un comité transversal et lesquelles peuvent couler à travers des portes automatisées, et enregistrez cet échelonnement explicitement, parce que « nous utilisons le jugement » n’est pas un contrôle qu’un auditeur ou un organisme de surveillance peut vérifier.
Quand avons-nous mené pour la dernière fois un audit de configuration fonctionnel et physique, et quelle part de la preuve serait un enregistrement vivant plutôt qu’une reconstruction ? Un audit de configuration fonctionnel confirme que le système fonctionne comme ses exigences le spécifient, et un audit de configuration physique confirme que les artefacts livrés correspondent à la configuration enregistrée et ne contiennent rien de non comptabilisé ; sautez-les et vous faites confiance que vos références et votre comptabilité de statut sont honnêtes sans jamais vérifier. La tension est le coût : les audits manuels sont lents et pénibles, ce qui est exactement pourquoi les équipes les reportent, et la sortie est d’automatiser les vérifications avec des constructions reproductibles, des sommes de contrôle d’artefacts, des nomenclatures logicielles, et des attestations de provenance afin que la vérification devienne continue. Apportez votre publication la plus récente et essayez de produire, sur place, la trace exigence-vers-changement-vers-construction-vers-déploiement et la preuve artefact-vers-source. Pour les programmes d’entreprise et gouvernementaux, cette piste de preuve est ce que la certification et la surveillance exigent, donc la question honnête est si l’audit de demain serait répondu depuis des enregistrements que vous détenez déjà ou depuis un exercice d’archéologie que vous ne pouvez pas vous permettre.

Regard sectoriel

Jeune pousse. Gardez la SCM légère mais réelle. Mettez la source, les définitions d’infrastructure, et les données de configuration dans le contrôle de version, et faites de chaque publication une construction étiquetée produite par un pipeline plutôt qu’un artefact assemblé à la main. Sautez les comités de contrôle des changements et les références formelles, qui sont excessifs à votre taille, mais ne laissez jamais quiconque éditer la configuration directement en production, parce que ce seul raccourci est ce qui rend une publication impossible à reproduire quand un client frappe un bug mardi prochain.

Petite entreprise. Sans gestionnaire de configuration et avec un budget serré, appuyez-vous sur des outils qui vous donnent la SCM presque gratuitement : une plateforme de contrôle de version hébergée, son pipeline intégré, et un registre d’artefacts, afin que l’enregistrement de configuration soit un sous-produit plutôt qu’un travail que vous devez doter en personnel. Achetez cette capacité intégrée dans des outils que vous payez déjà plutôt que de construire un processus sur mesure. Dépensez votre attention rare sur les deux habitudes qui comptent le plus, les publications étiquetées reproductibles et garder la configuration qui change le comportement hors des éditions manuelles de production.

Grande entreprise. Le problème est la cohérence à travers de nombreuses équipes : un plan SCM partagé, une taxonomie commune d’éléments de configuration, un contrôle de changement échelonné, et une comptabilité de statut générée automatiquement depuis le contrôle de version, le registre d’artefacts, et le pipeline. Réservez les comités de contrôle des changements formels et les références immuables pour les flux de plateforme partagée et réglementés, laissez les changements routiniers couler à travers des portes automatisées, et standardisez la provenance signée et les SBOM afin que la publication de n’importe quelle équipe puisse être tracée et que tout auditeur puisse interroger un enregistrement vivant au lieu de commander une reconstruction.

Gouvernement. Les règles de marchés publics, la transparence, et la responsabilité publique façonnent le processus. Suivez un plan SCM formel aligné sur une norme reconnue comme IEEE 828, fixez la référence des éléments de configuration aux jalons contractuels, et acheminez chaque changement à une référence contrôlée à travers un comité qui enregistre l’impact, la décision, et la justification. Exigez que les artefacts livrés soient reproductibles depuis des entrées contrôlées, avec somme de contrôle, et traçables de bout en bout depuis l’exigence approuvée jusqu’à la construction livrée, parce que cette piste de preuve documentée est exactement ce que la certification, l’audit, et la surveillance publique exigent.

Exemples

Jeune pousse. Une start-up de six personnes garde sa SCM légère mais réelle : la source, les définitions d’infrastructure, et les données de configuration vivent toutes dans le contrôle de version, et chaque publication est une construction étiquetée et versionnée produite par le même pipeline plutôt qu’assemblée à la main. Quand un client rapporte un bug apparu mardi dernier, ils tracent l’artefact déployé jusqu’au commit exact en quelques minutes au lieu de deviner. Ils sautent les comités de contrôle des changements et les références formelles, qui seraient excessifs à leur taille, mais ils refusent de laisser quiconque éditer la configuration directement en production, parce que ce seul raccourci est ce qui rend une publication impossible à reproduire plus tard.

Grande entreprise. Une grande société de services financiers place tous les artefacts déployables, définitions d’infrastructure, et données de configuration sous contrôle de configuration. Chaque publication est une référence immuable et versionnée avec une nomenclature logicielle générée, et chaque artefact déployé porte une attestation de provenance signée le liant à une révision source et une exécution de pipeline spécifiques. Les changements d’application routiniers coulent à travers des portes de pipeline automatisées, tandis que les changements aux références de plateforme partagée ou aux flux de paiement réglementés vont à un comité de contrôle des changements. La comptabilité de statut est générée automatiquement depuis le contrôle de version, le registre d’artefacts, et le pipeline, donc les auditeurs interrogent un enregistrement vivant au lieu de demander une reconstruction.

Gouvernement. Un programme de défense suit un plan SCM formel aligné sur IEEE 828. Les éléments de configuration sont listés et référencés aux jalons contractuels, et un comité de contrôle des changements autorise chaque changement à une référence contrôlée, enregistrant l’impact, la décision, et la justification. Les audits de configuration fonctionnels confirment que le système livré satisfait les exigences spécifiées, et les audits de configuration physiques confirment que les artefacts livrés correspondent exactement à la configuration enregistrée. Les publications sont reproductibles depuis des entrées contrôlées, avec somme de contrôle, et traçables de bout en bout, de l’exigence approuvée à travers la demande de changement jusqu’à la construction livrée, ce qui est exactement la piste de preuve que la certification et la surveillance exigent.

Argumentaire économique : motivations, retour sur investissement et coût total de possession

La SCM existe pour contrôler le risque et le coût à travers la vie d’un système. Le retour vient de la reproductibilité et de la traçabilité : vous pouvez recréer toute publication, tracer les défauts jusqu’aux changements qui les ont causés, et répondre aux questions d’audit depuis des enregistrements au lieu de l’archéologie. Cela réduit le temps de diagnostic d’incident, réduit le coût et la durée des audits, et prévient la classe d’échec coûteuse où personne ne peut dire ce qui fonctionne ou comment le reconstruire.

Le coût total de possession favorise l’automatisation. Les enregistrements de configuration manuels sont peu coûteux à démarrer et constamment coûteux à maintenir, et ils échouent exactement quand vous en avez le plus besoin, pendant un incident ou un audit, parce qu’ils ont dérivé de la réalité. L’identification, la comptabilité, et l’audit automatisés coûtent plus cher en amont mais transforment l’enregistrement de configuration en un sous-produit presque gratuit du pipeline de livraison. Pour convaincre la direction, présentez la SCM comme le contrôle qui rend les publications reproductibles et les changements auditables, et pesez-le contre le coût des publications irreproductibles, des audits prolongés, et le risque de conformité du changement incontrôlé.

Anti-patterns et pièges

La configuration par connaissance tribale : le vrai contenu d’une publication vit seulement dans la tête d’un ingénieur, pas dans un enregistrement.
Les références mutables : « la publication » est éditée en place, donc elle ne peut plus être reproduite ou fiable comme référence.
Les données de configuration incontrôlées : le code est sous contrôle de version mais la configuration qui change son comportement est éditée ad hoc en production.
Le théâtre de contrôle de changement : un comité qui approuve tout automatiquement, ajoutant du délai sans ajouter de vrai examen.
La comptabilité de statut manuelle : un tableur de versions qui diverge silencieusement de ce qui est réellement déployé.
Les constructions irreproductibles : des publications qui ne peuvent pas être reconstruites depuis des entrées contrôlées, donc les audits et reconstructions deviennent des suppositions.
Les publications non traçables : aucune correspondance de l’artefact déployé en arrière vers la révision source, la demande de changement, et l’approbation.

Modèle de maturité

Niveau 1 (Initiation) : La SCM est ad hoc et réactive. Seule la source est contrôlée ; les publications sont assemblées à la main ; il n’y a pas de références, pas d’enregistrement fiable de ce qui est déployé, et pas de moyen de reproduire une construction passée.
Niveau 2 (Développement) : Des pratiques de base existent mais varient d’équipe en équipe. Certains systèmes définissent des éléments de configuration et un processus de changement et versionnent leurs publications, des références existent ici et là, mais les enregistrements sont partiellement manuels et la rigueur du contrôle est incohérente à travers l’organisation.
Niveau 3 (Standardisation) : Les pratiques sont documentées et appliquées à l’échelle de l’organisation. Une taxonomie commune d’éléments de configuration, des références immuables, un contrôle de changement échelonné, et une comptabilité de statut sont établis et largement automatisés ; les publications sont reproductibles et traçables, et les audits sont soutenus par l’outillage plutôt que par la mémoire.
Niveau 4 (Gestion) : La SCM est mesurée et contrôlée avec des données. Le taux de reproductibilité, la couverture de traçabilité de l’exigence à l’artefact déployé, le délai de changement à travers chaque palier de contrôle, les incidents de dérive de configuration, et les conclusions d’audit sont suivis par rapport à des références et cibles. Les déviations déclenchent une correction, et chaque décision de poursuivre ou non repose sur cette preuve plutôt que sur une affirmation.
Niveau 5 (Orchestration) : La SCM est continuellement améliorée et intégrée à travers l’organisation. Entièrement automatisé et continuellement vérifié avec des constructions reproductibles, des SBOM, des attestations de provenance, et une comptabilité de statut vivante, le processus est tissé dans la livraison, la sécurité, et l’audit, et il s’adapte à mesure que le risque et les résultats de livraison changent, retirant et recadrant les contrôles sur preuve.

Pistes de réflexion

Pouvez-vous reproduire exactement votre dernière publication depuis des entrées contrôlées aujourd’hui, et combien de temps cela prendrait-il ?
Quels éléments de configuration déterminent le comportement mais ne sont pas réellement sous contrôle, spécialement les données de configuration et l’infrastructure ?
Votre contrôle de changement est-il échelonné par risque, ou ajoute-t-il des frais généraux uniformes ou un laxisme uniforme partout ?
Où vit votre enregistrement de configuration, et à quel point a-t-il dérivé de ce qui est réellement déployé ?
Quelle preuve pourriez-vous produire dans un audit demain, et quelle part serait de la reconstruction plutôt que de l’enregistrement ?
Comment les constructions reproductibles, les SBOM, et la provenance changent-ils ce que vos audits peuvent vérifier automatiquement ?

Points clés à retenir

La SCM contrôle toute la configuration (code, dépendances, infrastructure, et données de configuration), pas seulement la source.
Les références sont des points de référence immuables ; le changement est autorisé et enregistré contre elles, pas empêché.
La comptabilité de statut doit vous laisser répondre, à tout moment, à ce que contient une publication et comment elle est arrivée là.
Les audits vérifient que ce qui a été construit et livré correspond à la configuration enregistrée et aux exigences approuvées.
Échelonnez le contrôle par risque et automatisez l’identification, la comptabilité, et l’audit afin que l’enregistrement soit un sous-produit de la livraison.

Références et lectures complémentaires

IEEE Computer Society, SWEBOK Guide (Guide to the Software Engineering Body of Knowledge), domaine de connaissance Gestion de Configuration Logicielle
IEEE Std 828, Standard for Configuration Management in Systems and Software Engineering
ISO/IEC/IEEE 12207, Systems and software engineering: Software life cycle processes (processus de gestion de configuration)
Jez Humble et David Farley, Continuous Delivery
Bob Aiello et Leslie Sachs, Configuration Management Best Practices: Practical Methods that Work in the Real World
Guide NIST sur la sécurité de la chaîne d’approvisionnement logicielle, les nomenclatures logicielles (SBOM), et la provenance d’artefacts
CNCF et normes ouvertes pour la provenance de construction et l’attestation (comme cadres de référence)