Marchés publics et méthode agile : les rendre compatibles
La commande publique demande de définir le besoin à l'avance ; la méthode agile le découvre en avançant. Les deux se concilient, à condition de figer le cadre plutôt que le contenu.
Le constat revient dans beaucoup d’administrations : on veut travailler par petites livraisons, avec les usagers, en ajustant au fil de l’eau, et le service des marchés demande un cahier des charges complet avant de lancer la consultation. Les deux exigences paraissent incompatibles. Elles ne le sont pas. Les marchés agiles reposent sur une idée simple : figer le cadre de travail, laisser ouvert le contenu de chaque itération.
Ce guide s’appuie sur le droit français de la commande publique, mais la logique vaut dans la plupart des systèmes inspirés des directives européennes de 2014.
Ce que le droit exige vraiment
Le Code de la commande publique impose de définir le besoin avec précision avant de consulter. Il n’impose pas de décrire chaque écran ou chaque fonction. Un besoin peut être défini par ses objectifs (ce que le service doit permettre), par des exigences de résultat (accessibilité, sécurité, performance), par un mode de travail (itérations, démonstrations, critères d’acceptation) et par des unités d’œuvre dont on fixe le prix.
La difficulté n’est donc pas d’interdire l’agilité. Elle est de rendre le marché contrôlable : l’acheteur doit pouvoir dire ce qu’il paie, pourquoi, et vérifier ce qu’il reçoit.
Les montages possibles
- Prix fixés par unité d’œuvre (journée d’un profil, lot de fonctionnalités de taille donnée)
- Chaque itération fait l’objet d’un bon de commande
- Montant maximal à fixer dès la consultation
- Souplesse forte, mais pilotage exigeant côté acheteur
- Une tranche ferme (découverte, premier produit utilisable)
- Des tranches optionnelles, affermies une à une
- Points de décision clairs : continuer, réorienter, arrêter
- Contenu des tranches plus difficile à décrire à l’avance
Les deux montages se combinent souvent : une tranche ferme de découverte, puis un accord-cadre pour la construction. D’autres procédures existent pour des besoins particuliers : le dialogue compétitif quand l’acheteur ne sait pas définir seul la solution, le partenariat d’innovation quand il faut une recherche et développement, et le dispositif d’achats innovants sans publicité en dessous d’un seuil fixé par décret.
Rédiger la consultation, étape par étape
- Écrire l’objectif en termes d’usage : qui doit pouvoir faire quoi, en combien de temps, avec quel niveau de service. Une page suffit.
- Fixer les exigences non négociables : accessibilité (RGAA), sécurité, hébergement, protection des données, propriété du code.
- Décrire le mode de travail : durée des itérations, démonstrations, rôle du responsable produit côté acheteur, définition de « terminé ».
- Définir les unités d’œuvre et leur contenu. Des profils au temps passé, des unités forfaitaires de complexité, ou un mélange des deux.
- Préparer un cas pratique commun à tous les candidats, pour comparer les chiffrages avec les mêmes hypothèses.
- Choisir les critères : compréhension du besoin, composition de l’équipe, méthode, prix. Donner un poids réel à l’équipe nommée et prévoir son maintien.
- Prévoir la sortie : réversibilité, documentation, transfert de compétences, durée raisonnable de l’accord-cadre.
Un bon marché agile répond à trois questions sans ambiguïté : qui décide du contenu de chaque itération, comment on accepte une livraison, et comment on arrête.
Piloter l’exécution
La plupart des échecs ne viennent pas du marché, mais de l’absence d’un responsable produit côté acheteur, disponible et habilité à arbitrer. Sans lui, le prestataire décide seul du contenu, ou attend. Ce rôle prend du temps : souvent plusieurs jours par semaine. Il doit être prévu dans l’organisation avant la notification.
Le contrôle se fait par la démonstration et les critères d’acceptation, pas par des rapports d’avancement. Chaque bon de commande décrit un objectif d’itération ; chaque fin d’itération donne lieu à une démonstration, à une acceptation (ou un refus motivé) et à une mise à jour du carnet de produit. Ce carnet, partagé, devient la trace des décisions.
Un accord-cadre agile n’autorise pas à changer l’objet du marché. Si le projet dérive vers un tout autre service, il faut une nouvelle consultation, pas une suite de bons de commande.
Fixer le prix sans figer le contenu
Le prix est souvent le point de blocage. Trois approches coexistent. Le temps passé par profil (une journée de développeur, de concepteur, d’expert en accessibilité) est simple à commander, mais transfère le risque de productivité à l’acheteur. Les unités forfaitaires de complexité (une fonctionnalité simple, moyenne ou complexe, définie par des exemples dans le marché) partagent mieux le risque, à condition que les catégories soient décrites avec soin. L’équipe forfaitaire par itération (une équipe donnée, pour deux semaines, à un prix fixe) donne de la visibilité budgétaire et oblige à bien préparer chaque itération.
| Approche | Avantage | Point de vigilance |
|---|---|---|
| Temps passé par profil | Simple à commander et à contrôler | Le risque de productivité reste chez l’acheteur |
| Unités de complexité | Paiement lié à ce qui est livré | Définitions des catégories à rédiger avec précision |
| Équipe forfaitaire par itération | Budget prévisible, rythme régulier | Exige un carnet de produit prêt à chaque itération |
Dans tous les cas, le cas pratique de la consultation sert de référence : chaque candidat le chiffre avec la même approche, ce qui rend les offres comparables et donne un étalon pour contrôler les bons de commande pendant l’exécution.
Les questions à se poser avant de lancer
Le cadre juridique est connu ; le vrai sujet est la maturité de l’acheteur. Dispose-t-on d’un responsable produit nommé ? Les usagers peuvent-ils être associés aux démonstrations ? Le service des marchés et la direction métier ont-ils lu ensemble la consultation ? Le contrôle financier accepte-t-il un paiement par itération ?
Ces questions relèvent de la neutralité de l’acheteur autant que de sa méthode : un marché bien construit protège contre la dépendance à un prestataire unique. C’est l’objet de l’expertise neutralité de DOSOBE, et le dossier sur l’achat numérique public en développe le cadre général. Reste une question ouverte pour chaque organisation : est-on prêt à décider toutes les deux semaines, plutôt qu’une fois au début ?
Questions fréquentes
La méthode agile est-elle compatible avec le Code de la commande publique ?
Oui. Le code impose de définir le besoin avec précision avant la consultation, mais un besoin peut être défini par ses objectifs, ses exigences de résultat et le mode de travail attendu. Plusieurs acheteurs publics passent des marchés de développement en mode agile, en général sous forme d'accord-cadre à bons de commande.
Comment comparer les offres si le contenu n'est pas figé ?
Sur la qualité de l'équipe proposée, la méthode, la compréhension du besoin et le prix des unités d'œuvre. Un cas pratique, chiffré par chaque candidat avec les mêmes hypothèses, aide à comparer les prix de façon loyale.
Peut-on changer de prestataire en cours de projet ?
Oui, si le marché le prévoit : tranches optionnelles, durée courte, clauses de réversibilité, propriété du code et de la documentation. Ces clauses se rédigent dès la consultation.