Cahier de clauses de livraison continue numérique (2022)

Code : Commande Publique

L’arrêté du 14 décembre 2021 approuve le « cahier de clauses de livraison continue numérique », applicable en complément du CCAG TIC. Ce cahier de clauses n’est applicable qu’aux marchés qui s’y réfèrent.
Ces clauses visent d’abord des livraisons de logiciels réalisés à façon, pour le compte de l’acheteur ou de ses bénéficiaires. Dans le cadre de produits sur étagère, ces clauses couvrent aussi des modules sur commande ou des codes de configuration, configurations considérées comme des sources y compris pour des infrastructures.

CAHIER DE CLAUSES DE LIVRAISON CONTINUE NUMÉRIQUE

Article 1 – Champ d’application

Ce cahier de clauses n’est applicable qu’aux marchés qui s’y réfèrent.
Ces clauses visent d’abord des livraisons de logiciels réalisés à façon, pour le compte de l’acheteur ou de ses bénéficiaires. Dans le cadre de produits sur étagère, ces clauses couvrent aussi des modules sur commande ou des codes de configuration, configurations considérées comme des sources y compris pour des infrastructures.

Article 2 – Chaîne d’intégration et de déploiement

Cette chaîne comprend l’ensemble des étapes de construction et de configuration de composants logiciels à partir de codes sources pour fournir un service opérationnel sur les environnements visés.
Cette chaîne fournit des points d’accroche pour réaliser des tests pré- et post-construction, pré- et post-déploiement.
Pour des développements en cycles courts, comme des correctifs d’urgence pour performance ou sécurité, l’objet d’une chaîne d’intégration et de déploiement continu est de la traverser en moins d’une journée, toutes les étapes et tests inclus, grâce à l’automatisation.

Article 3 – Forge logicielle

La forge est un gestionnaire de codes sources qui permet l’attribution nominative de toutes les lignes de code à une personne physique et comporte aussi un espace d’échanges autour du code : revues de codes, suivi des correctifs, des demandes d’évolutions…
A défaut d’accord spécifique entre fournisseur et acheteur, le fournisseur utilise la forge mise à disposition par l’acheteur. Dans tous les cas, l’acheteur doit pouvoir suivre en continu les étapes successives de développement des codes, depuis la création jusqu’au retrait des composants du SI du commanditaire, en assurant la réversibilité.

Article 4 – Modularisation

Le code est partitionné et variabilisé selon les indications définies avec l’acheteur, par exemple entre la source du code principal et les sources des configurations des différents environnements.

Article 5 – Nom de versions

Le titulaire suit la politique de gestion des versions indiquée par l’acheteur. A défaut, il utilise les conventions de gestion sémantique de version https://semver.org/lang/fr.

Article 6 – Fréquence de livraison

En période de développement, le fournisseur réalise une livraison au minimum hebdomadaire, dans un état stable et susceptible d’être déployée.

Article 7 – Dépendances

La livraison de sources comprend la description exhaustive des dépendances et des chaînes d’outils permettant à l’acheteur de reproduire les livrables à partir d’outils dont il dispose.
Le titulaire alerte si les technologies qu’ils utilisent ne permettent pas des constructions reproductibles https://reproducible-builds.org/.

Article 8 – Livraisons d’artéfacts et empaquetage

Le format de livraison est choisi par l’acheteur. A défaut d’indication, le fournisseur fournit des paquets au format natif des plateformes cibles utilisées pour les déploiements : .msix pour Windows.deb pour Debian,.oci pour Docker, etc. Dans ce cas, les pratiques des plateformes s’appliquent (nommage, répertoire par défaut, etc.).

Article 9 – Documentation intégrée

En plus des documentations réglementaires, les livraisons incluent les formats habituels de documentation intégrés aux plateformes (pages man dans les environnements Unix, fichiers.chm dans les environnements Windows, etc.).

Article 10 – Déploiements continus

Le titulaire conçoit ses livraisons en vue de l’automatisation complète des déploiements dans les environnements de l’acheteur ou des bénéficiaires. A ce titre, il respecte les indications de l’hébergeur, ou, à défaut, les conventions d’usage pour les chemins de répertoires et fichiers, afin que les automates trouvent les composants.

Article 11 – Tests automatisés

Le fournisseur inclut dans ses livraisons, des tests automatisés qui permettent de franchir les étapes de la chaîne d’intégration (construction, déploiement…) sans crainte de régression.

Article 12 – Déploiement minimal

Dès que possible, une livraison minimale est déployée jusqu’à un environnement désigné par l’acheteur. A défaut de précision, ce déploiement est réalisé sur un environnement de production.
Aucun paiement ou acompte pour travaux réalisés (ce qui exclut les acomptes à la commande) ne peut intervenir avant ce déploiement minimal.
Les déploiements ultérieurs sont réalisés par montée de version.

Article 13 – Migrations

Les montées de version incluent les migrations automatisées de données (schéma SQL, stockages de tables, etc.).

Article 14 – Fréquence des déploiements

En période de développement intensif, la fréquence des déploiements est définie par l’acheteur et le titulaire réalise le packaging pour répondre à la fréquence de déploiement définie. A défaut, le titulaire doit être en capacité de réaliser des déploiements hebdomadaires.
En période de maintenance, la fréquence peut être ramenée à deux livraisons par an, pour, à minima, permettre l’inclusion de correctifs de sécurité et d’évolutions des plateformes.

Article 15 – Intégration métrologie, journaux, supervision

Le titulaire fournit les points d’intégration avec les pratiques de métrologie, journalisation et supervision de l’acheteur ou ses bénéficiaires.
A défaut d’indication, le fournisseur suit les préceptes de « 12 facteurs » https://12factor.net/fr/.