quand on aspire à des méthodes de développement Agiles ?
Il y a bientôt un an, notre pôle ministériel a publié au Journal Officiel un cahier de clauses types. Contrairement à sa rédaction réalisée en quelques semaines, son principe même a fait l’objet de débats internes. En particulier, certains défendaient qu’il ne fût pas souhaitable de créer encore un cadre, encore des « règlements ». Visiblement, ces arguments n’ont pas été totalement décisifs. Voici pourquoi.
Le mouvement Agile est effectivement né en réaction des caricatures que sont devenus certains projets informatiques. Des mois voire des années à rédiger des spécifications, un délai équivalent pour réaliser les développements eux-mêmes pour aboutir à un produit souvent « à côté de la plaque » : entre-temps, les attentes des utilisateurs ont évolué et surtout il y a une différence notable entre préférences déclarées et préférences révélées (phénomène bien connu dans les transports), entre préférences sur catalogue et préférences devant un produit matérialisé (phénomène bien connu dans le prêt-à-porter). A contrario, le mouvement Agile promeut des cycles courts de développement, généralement appelés des Sprints, pour que les utilisateurs finaux guident les réalisations tout au long du développement en évaluant des prototypes.
Mais les différentes tonalités de l’Agilité n’ont pas retiré le besoin de structurer le travail de conception, bien au contraire. Pour véritablement impliquer les utilisateurs dans le travail des développeurs, une maquette qui tourne uniquement sur le PC de développement et accessible une demi-journée par semaine n’est pas suffisante. Il vaut mieux un environnement serveur qui expose en permanence la dernière version. Pour prolonger l’analogie sportive, les Sprints ne se limitent pas au stade d’échauffement mais viennent s’exposer au Public, dans des épreuves de secondes catégories avant les grandes compétitions internationales. C’est pourquoi implicitement ou explicitement, les méthodes Agiles formalisées (par rapport à l’acceptation courante) préconisent toutes l’intégration et les tests continus.
Maintenant, si on fait la lecture des clauses incluses par défaut dans les marchés publics, rien n’est dit. Si les clauses de paiement (droit à acompte, à paiement direct, pénalité et réfaction sur facture, etc) sont encadrées, c’est un silence assourdissant sur les conditions de livraison des produits numériques. Petit à petit, le CCTG « NTIC » a intégré la dérégulation du secteur des télécommunications, et notamment la spécificité de facturation des abonnements avant fourniture du service. Mais pour le reste, les seuls concepts contractuels proposés sont ceux de la VABF (vérification aptitude au bon fonctionnement) et de la VSR (vérification de service régulier), parfaitement adaptés à des produits sur étagère mais certainement pas à des développements à façon.
Dès lors, comment s’étonner que les acteurs des contrats découvrent post-signatures que leur compréhension des pratiques de livraison sont « différentes » : où est le code source de référence ? comment est-il compilé et testé automatiquement ? déployé ? Chacun se doute qu’en matière de contrat, il vaut mieux être explicite qu’implicite. Plutôt que de refuser de rédiger, il faut être souple dans la rédaction. C’est le parti pris qui a été retenu dans le texte publié.
Pour commencer, ce texte n’est opposable qu’aux appels d’offres qui y font référence. Tout au plus, dans le cas d’un projet de notre pôle ministériel , on peut déduire les pratiques attendues par défaut. Mais libre à chaque entité ou organisme de choisir de s’appuyer explicitement sur ces clauses. Elles ne sont pas non plus exclusives, dans le sens où un autre ministère, une collectivité territoriale voire une entreprise privée peut tout autant en faire usage. Ce n’est ni plus ni moins qu’une liste de conventions explicites pour travailler à la livraison de produits numériques dans un cadre contractuel.
Enfin, chaque article définit une valeur par défaut mais laisse la place à l’accord entre les parties. Par exemple, l’article 3 prévoit que le gestionnaire de code source soit celui du commanditaire. Mais s’il est d’accord pour s’appuyer sur celui du fournisseur ou d’un tier comme Github, notamment pour des projets open source, l’article délègue à l’accord entre les parties.
Voir en ligne : Arrêté du 14 décembre 2021 portant approbation d’un cahier de clauses de livraison continue numérique
Flexibles dans les détails mais structurantes dans la manière d’aborder des livraisons numériques, les clauses types permettent de contractualiser avec des développeurs en alignant intention d’Agilité et relations fournisseurs.