Section parente

Arrêté du 14 décembre 2021

JORF n°0008 du 11 janvier 2022

Annexe

ANNEXE
CAHIER DE CLAUSES DE LIVRAISON CONTINUE NUMÉRIQUE

1 version

Article 1

Ce texte est une simplification générée par une IA.
Il n'a pas de valeur légale et peut contenir des erreurs.

Champ d'application

Résumé Ce document ne s'applique qu'aux marchés qui le mentionnent et concerne les logiciels faits sur mesure ainsi que les modules et codes personnalisés.

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.

1 version

Article 2

Ce texte est une simplification générée par une IA.
Il n'a pas de valeur légale et peut contenir des erreurs.

Chaîne d'intégration et de déploiement de logiciels

Résumé La chaîne d'intégration et de déploiement transforme le code en service opérationnel en moins d'une journée pour des corrections urgentes, avec des tests à chaque étape.

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.

1 version

Article 3

Ce texte est une simplification générée par une IA.
Il n'a pas de valeur légale et peut contenir des erreurs.

Utilisation de la forge logicielle

Résumé La forge logicielle permet de suivre qui a écrit chaque ligne de code et de discuter des changements, l'acheteur doit pouvoir voir toutes les étapes de développement.

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é.

1 version

Article 4

Ce texte est une simplification générée par une IA.
Il n'a pas de valeur légale et peut contenir des erreurs.

Modularisation du code

Résumé Le code est organisé en parties pour être adapté aux besoins, en séparant le code principal des réglages pour différents environnements.

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.

1 version

Article 5

Ce texte est une simplification générée par une IA.
Il n'a pas de valeur légale et peut contenir des erreurs.

Gestion des versions des logiciels

Résumé Le fournisseur doit suivre les règles de gestion des versions de l'acheteur, sinon utiliser celles de semver.org.

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.

1 version

Article 6

Ce texte est une simplification générée par une IA.
Il n'a pas de valeur légale et peut contenir des erreurs.

Fréquence de livraison en période de développement

Résumé En développement, le fournisseur doit livrer au moins une fois par semaine et que ce soit stable.

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.

1 version

Article 7

Ce texte est une simplification générée par une IA.
Il n'a pas de valeur légale et peut contenir des erreurs.

Obligation de description exhaustive des dépendances

Résumé Le titulaire doit fournir une liste complète des outils nécessaires pour reproduire les livrables et dire si les technologies ne permettent pas de le faire.

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/.

1 version

Article 8

Ce texte est une simplification générée par une IA.
Il n'a pas de valeur légale et peut contenir des erreurs.

Format de livraison des artefacts

Résumé Le fournisseur livre les artefacts dans le format standard des plateformes si l'acheteur ne spécifie rien.

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.).

1 version

Article 9

Ce texte est une simplification générée par une IA.
Il n'a pas de valeur légale et peut contenir des erreurs.

Documentation intégrée dans les livraisons de logiciels

Résumé Les logiciels doivent inclure des aides intégrées pour chaque système.

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.).

1 version

Article 10

Ce texte est une simplification générée par une IA.
Il n'a pas de valeur légale et peut contenir des erreurs.

Déploiements continus

Résumé Le fournisseur doit faire ses livraisons de manière à ce qu'elles puissent être installées automatiquement dans les systèmes de l'acheteur, en suivant les règles de l'hébergeur ou les normes d'usage.

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.

1 version

Article 11

Ce texte est une simplification générée par une IA.
Il n'a pas de valeur légale et peut contenir des erreurs.

Tests automatisés dans les livraisons

Résumé Les fournisseurs doivent inclure des tests automatisés pour éviter les problèmes lors de l'intégration.

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.

1 version

Article 12

Ce texte est une simplification générée par une IA.
Il n'a pas de valeur légale et peut contenir des erreurs.

Déploiement minimal d'une livraison

Résumé Une première version doit être installée avant tout paiement.

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.

1 version

Article 13

Ce texte est une simplification générée par une IA.
Il n'a pas de valeur légale et peut contenir des erreurs.

Migrations des données lors des montées de version

Résumé Les mises à jour de version incluent des transferts automatiques des données pour les maintenir intactes.

Migrations

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

1 version

Article 14

Ce texte est une simplification générée par une IA.
Il n'a pas de valeur légale et peut contenir des erreurs.

Fréquence des déploiements pendant les périodes de développement et de maintenance

Résumé Le nombre de mises en service dépend de la phase, et en maintenance, deux fois par an suffit pour les mises à jour de sécurité.

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.

1 version

Article 15

Ce texte est une simplification générée par une IA.
Il n'a pas de valeur légale et peut contenir des erreurs.

Intégration des pratiques de métrologie, journalisation et supervision

Résumé Le fournisseur doit suivre les règles de l'acheteur pour la métrologie, la journalisation et la supervision, sinon il utilise les "12 facteurs".

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/.

1 version