Cahier des charges d'une TMA Drupal pour un marché public : les clauses à prévoir

Un marché de TMA Drupal se joue presque entièrement dans son cahier des charges. S'il décrit précisément le site, le périmètre, la façon de mesurer les niveaux de service et la sortie du contrat, les offres deviennent comparables et l'exécution se passe sans surprise. S'il reste flou, vous recevez des offres impossibles à départager, et les désaccords arrivent pendant l'exécution, au moment où ils coûtent le plus cher.

Cet article s'adresse aux DSI, chefs de projet et responsables communication qui rédigent ou renouvellent le marché de maintenance d'un site Drupal. Il liste les clauses à prévoir, les pièges fréquents et se termine par une checklist. Il ne remplace pas l'avis de votre service juridique ou de la commande publique : les références citées sont à revérifier au moment de lancer votre consultation.

Avant d'écrire : un état des lieux du site

On ne peut pas décrire un périmètre de maintenance sans savoir ce que l'on maintient. Joignez au dossier de consultation un inventaire technique, même sommaire :

• la version de Drupal et de PHP en production (le vérificateur de version Drupal donne une première indication) ;
• la liste des modules contribués et des modules ou thèmes développés sur mesure ;
• les intégrations : authentification unique, formulaires reliés à un logiciel métier, flux d'import, paiement, moteur de recherche ;
• l'hébergement, les environnements existants et l'emplacement du code (dépôt Git ou non) ;
• les volumes utiles : nombre de contributeurs, langues, pics de fréquentation connus.

Si personne en interne ne peut établir cet inventaire, commandez-le avant le marché : un audit préalable fournit une base factuelle que tous les candidats liront de la même façon. Les candidats chiffrent alors le même site, et non chacun leurs propres hypothèses.

Le montage : accord-cadre, durée et seuils

La TMA mêle une part récurrente (veille de sécurité, mises à jour, surveillance) et une part à la demande (corrections, évolutions). L'accord-cadre à bons de commande s'y prête bien. Selon la fiche technique de la DAJ mise à jour le 13 mars 2026, il comporte obligatoirement un maximum, en valeur ou en quantité (article R. 2162-4 du code de la commande publique), et sa durée ne peut pas dépasser quatre ans pour un pouvoir adjudicateur, sauf cas exceptionnels justifiés (article L. 2125-1).

Côté procédure, deux évolutions récentes sont à connaître :

• depuis le 1er avril 2026, le seuil de dispense de procédure pour les marchés de fournitures et de services est de 60 000 € HT (décret n° 2025-1386 du 29 décembre 2025) ;
• depuis le 1er janvier 2026 et pour 2026-2027, les seuils européens de procédure formalisée sont de 216 000 € HT pour les collectivités territoriales et de 140 000 € HT pour l'État, en fournitures et services.

La valeur à comparer à ces seuils est celle du besoin sur toute la durée du marché, reconductions comprises. Votre service de la commande publique tranchera ; l'essentiel, côté technique, est de fournir une estimation réaliste du volume de demandes attendu.

Le périmètre : quatre volets, et ce qui en est exclu

Décrivez chaque volet de la maintenance séparément, avec ce qu'il comprend concrètement :

Écrivez aussi ce qui n'en fait pas partie : l'hébergement si un autre prestataire en a la charge, la saisie de contenus, la formation des contributeurs, les refontes graphiques. Une exclusion écrite évite un litige, une exclusion implicite en crée un.

La page TMA détaille ces quatre volets du point de vue du prestataire.

Versions et fins de vie : la clause que l'on oublie

Un marché de quatre ans traversera au moins une fin de vie. Drupal 10 ne reçoit plus de correctifs de sécurité après le 9 décembre 2026, la semaine où Drupal 12 est prévu. PHP retire chaque année une version de son support de sécurité. Les dates à jour sont regroupées sur la page fins de vie Drupal, PHP et Symfony.

Le cahier des charges doit donc répondre à deux questions :

• Qui réalise la montée de version majeure, et selon quel mécanisme : prestation chiffrée dans le bordereau de prix, bon de commande sur devis, ou marché distinct ?
• À quel moment : par exemple, une obligation pour le titulaire d'alerter par écrit un délai raisonnable avant chaque fin de support, avec une estimation de l'effort.

Sans cette clause, le titulaire peut soutenir, à juste titre, qu'une montée de version majeure n'entre pas dans la maintenance courante, et vous vous retrouvez à devoir lancer une procédure dans l'urgence.

Niveaux de service : les définir et savoir les mesurer

Les valeurs des niveaux de service vous appartiennent : elles dépendent de la criticité de votre site. Ce que le cahier des charges doit fixer, c'est leur définition :

• une classification des incidents : site inaccessible, fonctionnalité bloquante, anomalie mineure ;
• la distinction entre délai de prise en charge (quelqu'un a qualifié le problème) et délai de rétablissement (le service fonctionne à nouveau, éventuellement par un contournement) ;
• les jours et plages couverts, écrits explicitement ;
• l'outil qui fait foi pour horodater les demandes : un outil de tickets partagé plutôt qu'une boîte e-mail ;
• les pénalités éventuelles, proportionnées et calculées sur des indicateurs mesurables.

Le calendrier de Drupal aide à dimensionner la veille de sécurité : les versions de sécurité sont publiées dans une fenêtre fixe, le troisième mercredi de chaque mois, avec de rares publications hors calendrier annoncées à l'avance.

Je travaille seul et je ne propose pas d'astreinte 24/7. Si votre site exige une disponibilité en dehors des jours ouvrés, dites-le clairement et séparez ce besoin de la maintenance applicative (voir l'allotissement plus bas).

Réversibilité, propriété du code et documentation

Le CCAG-TIC (arrêté du 30 mars 2021) comporte des stipulations sur la réversibilité et sur la propriété intellectuelle, dont la possibilité de diffuser les logiciels sous licence libre. Il ne s'applique que si votre marché s'y réfère, et le CCAP doit lister les dérogations.

Drupal est distribué sous licence GPL version 2 ou ultérieure. Pour le code écrit spécifiquement pour vous (modules, thème), prévoyez au minimum :

• un dépôt Git ouvert à votre nom, dans lequel le titulaire travaille ; pas une copie remise en fin de contrat ;
• les droits d'utilisation, de modification et de cession à un tiers, y compris le prestataire suivant ;
• une documentation d'exploitation tenue à jour : installation, déploiement, tâches planifiées, dépendances externes ;
• une phase de réversibilité décrite : livrables remis, transfert de connaissances, durée, et assistance au repreneur.

Le meilleur test : un autre prestataire doit pouvoir reprendre le site à partir du dépôt et de la documentation, sans l'aide du titulaire sortant.

Hébergement, accès, préproduction et recette

Précisez qui détient quoi. Les comptes d'hébergement, le nom de domaine et les services tiers restent au nom de l'organisme ; le titulaire reçoit des accès nominatifs, révocables en fin de marché.

Exigez un environnement de préproduction proche de la production, et décrivez le circuit : développement, recette par vos équipes sur la préproduction, validation écrite, mise en production, avec une procédure de retour arrière. Fixez aussi la durée de la période de recette et ce qui se passe si une anomalie est découverte après la mise en production.

Reporting et pilotage

Demandez un rapport périodique : mises à jour appliquées, incidents et délais constatés, interventions réalisées, points de vigilance à venir (fins de support, modules abandonnés). Ajoutez un comité de suivi à une fréquence réaliste pour votre structure. Ce rapport est aussi votre outil pour vérifier les niveaux de service et justifier d'éventuelles pénalités.

Sécurité, RGPD et accessibilité

Sécurité. Le CCAG-TIC prévoit des clauses sur les vulnérabilités, les audits de sécurité et la maintenance sécurisée. Précisez vos attentes : délai d'application des correctifs critiques, gestion des comptes, sauvegardes hors du serveur principal, signalement des incidents.

RGPD. Un site public traite des données personnelles (formulaires, comptes, journaux). Le titulaire est en général sous-traitant au sens du RGPD, et le contrat doit alors comporter les mentions de l'article 28. La CNIL recommande de traiter ces questions dès la rédaction du marché et renvoie aux clauses contractuelles types de la Commission européenne du 4 juin 2021.

Accessibilité. Les organismes publics sont soumis à une obligation d'accessibilité numérique. Le référentiel en vigueur à la date de rédaction est le RGAA 4.1.2. Exigez que les évolutions et les corrections ne dégradent pas l'accessibilité, et précisez qui réalise les audits de conformité : ce n'est pas nécessairement le titulaire de la TMA.

Des critères qui n'excluent pas les petites structures

La maintenance d'un site Drupal de taille moyenne peut être assurée par une petite équipe, voire par un indépendant. Quelques choix du cahier des charges permettent de ne pas les écarter sans raison :

• Allotir : un lot hébergement et infogérance, avec astreinte si nécessaire, et un lot maintenance applicative ; un lot audit d'accessibilité, le cas échéant. L'allotissement est la règle, et la dévolution en marché global doit être justifiée.
• Proportionner le chiffre d'affaires exigé : depuis le 1er janvier 2026, il ne peut pas dépasser une fois et demie le montant estimé du marché ou du lot, sauf cas exceptionnels justifiés.
• Évaluer la méthode plutôt que la taille : un mémoire technique noté sur un cas concret (un correctif de sécurité, une montée de version) en dit plus qu'un effectif.
• Demander un plan de continuité plutôt qu'un nombre minimal d'intervenants : absences planifiées, documentation, accès à votre nom, possibilité de reprise par un tiers.

Trois pièges fréquents

Exiger une astreinte disproportionnée. Une astreinte permanente pour un site institutionnel sans service transactionnel écarte les petites structures et renchérit toutes les offres. Réservez-la aux services qui en ont réellement besoin, dans un lot dédié.

Laisser le périmètre flou. « Maintenance du site » sans inventaire ni exclusions, c'est la garantie d'offres incomparables et de discussions sur chaque demande.

Oublier la montée de version majeure. C'est la dépense la plus prévisible d'un site Drupal. Elle doit figurer au marché, sous une forme ou une autre.

La checklist avant publication

• Inventaire technique du site joint au dossier de consultation
• Montage choisi (accord-cadre à bons de commande, maximum, durée) et valeur estimée sur toute la durée
• Quatre volets décrits, exclusions écrites
• Mécanisme prévu pour les montées de version majeures de Drupal et de PHP
• Classification des incidents, délais de prise en charge et de rétablissement, jours couverts, outil qui fait foi
• Dépôt Git au nom de l'organisme, droits sur le code, documentation, phase de réversibilité
• Accès nominatifs, préproduction, circuit de recette et retour arrière
• Rapport périodique et comité de suivi
• Clauses sécurité, article 28 du RGPD, exigences RGAA
• Allotissement étudié, capacités exigées proportionnées, astreinte limitée au besoin réel

Si votre site doit d'abord être remis à niveau avant d'entrer en maintenance, l'audit vous donne l'état des lieux à joindre au dossier. Le détail de ma propre formule de maintenance est sur la page TMA Drupal.

Sources, consultées en septembre 2026 : DAJ, Publication de deux décrets relatifs à la commande publique (décrets n° 2025-1386 et 2025-1383 du 29 décembre 2025) ; DAJ, Les seuils européens de procédure formalisée changent au 1er janvier 2026 ; DAJ, Fiche technique « Les accords-cadres » (mise à jour du 13 mars 2026) ; DAJ, Notice de présentation des CCAG 2021 ; marche-public.fr, décrets 2025-1386 et 2025-1383 (article R. 2142-7) ; CNIL, Clauses contractuelles types entre responsable de traitement et sous-traitant et guide sur la responsabilité des acteurs dans la commande publique ; accessibilite.numerique.gouv.fr (RGAA 4.1.2) ; drupal.org, Licensing et Core release cycle.