Support Drupal : ce que doit couvrir un forfait

La plupart de ceux qui cherchent du support Drupal possèdent déjà le site. Ils l’ont hérité d’une agence partie ailleurs, ou d’un développeur parti, et voilà qu’une mise à jour a du retard, qu’un formulaire n’envoie plus rien, ou qu’un avis de sécurité est tombé sans que personne sache s’il s’applique. Ce qu’ils veulent n’est pas une page commerciale. C’est un cahier des charges : en quoi consiste le travail, ce que dit un contrat honnête, et ce que cela doit coûter.

C’est l’objet de cet article : le travail dont un site Drupal a réellement besoin chaque mois, les faits opérationnels qui décident si un forfait vaut quelque chose, et des fourchettes de prix britanniques réalistes. Lisez-le avec la proposition d’un prestataire ouverte à côté, car l’utile est de repérer les questions auxquelles elle ne répond pas.

Deux choses distinguent Drupal de la maintenance de site ordinaire. Ses avis de sécurité suivent un calendrier publié, donc votre fenêtre d’exposition est mesurable et peut figurer au contrat. Et un site Drupal assemble des modules contribués aux mainteneurs indépendants, donc quelqu’un doit suivre pour vous une cible mouvante.

Que doit couvrir un forfait de support Drupal ? La surveillance des avis de sécurité qui visent exactement votre parc de modules, les mises à jour du cœur et des modules contribués selon un cycle défini via une préproduction, la preuve que les sauvegardes se restaurent vraiment, la surveillance de la disponibilité et des erreurs applicatives, et un budget de changement nommé pour les petits travaux. Au Royaume-Uni cela va d’environ £250 par mois pour un site vitrine simple à £2,000 ou plus pour un site complexe. En dessous, vous achetez de la surveillance, pas du support.

Ce que le support Drupal veut dire mois après mois

Demandez un devis à trois agences et vous recevrez trois offres nommées Essential, Business et Enterprise, chacune une liste à puces de substantifs. Les substantifs ne sont pas le travail. Le travail est un ensemble de tâches récurrentes qui se font selon un calendrier ou ne se font pas du tout, et l’exercice utile consiste à faire décrire chacune par le prestataire comme une activité, avec un responsable et une fréquence.

Il y en a huit. Surveillance des avis de sécurité et application des correctifs. Mises à jour du cœur et des modules contribués. Montées de version des dépendances et de la plateforme. Vérification des sauvegardes et tests de restauration. Surveillance de la disponibilité et des erreurs applicatives. Contrôle des régressions de performance. Support éditorial. Et un budget de changement pour les petits travaux qui arrivent toujours.

Un contrat qui nomme les huit n’est pas bon d’office, mais un contrat qui en nomme quatre est nettement incomplet, et les quatre absents sont presque toujours les mêmes : tests de restauration, régressions de performance, montées de version de plateforme et budget de changement. Ce sont les postes coûteux, d’où leur disparition.

Pourquoi les noms d’offres masquent le travail

“Tickets de support illimités” ne dit rien de qui applique un correctif de sécurité du cœur le troisième mercredi du mois. “Surveillance proactive” ne dit rien de savoir si un humain lit l’alerte à deux heures du matin ou si elle attend jusqu’à lundi. “Au mieux de nos moyens” ne dit rien du tout.

Remplacez chaque formule par trois faits : l’activité, sa fréquence et le rôle nommé qui l’exécute. La plupart des pages d’offres se dissolvent sous ce traitement, et celles qui survivent désignent les prestataires avec qui parler.

La fenêtre de correctifs est tout le produit

Drupal publie ses versions de sécurité selon un calendrier, ce qui est inhabituel et immensément utile. Les versions de sécurité du cœur sortent dans une fenêtre le troisième mercredi du mois , à partir de 1200 America/New York, soit 1600 ou 1700 UTC selon la saison. Les projets contribués disposent d’une fenêtre de sécurité chaque mercredi , donc les avis contribués arrivent bien plus souvent que ceux du cœur, et par lots.

La conséquence est que la vulnérabilité n’est pas le risque. Tous ceux qui font tourner Drupal reçoivent la même vulnérabilité au même instant, publiée au grand jour. Le risque est l’écart entre la mise en ligne de l’avis et l’arrivée du correctif sur votre site de production, car pendant cet écart la faille est documentée, indexée et recherchée par des gens qui ont lu l’avis plus vite que votre prestataire.

Toute autre clause d’un contrat de support est décorative à côté du nombre d’heures de cet écart. La première question à poser à un prestataire relève donc de l’arithmétique, pas de la philosophie. Le troisième mercredi du mois prochain, à quelle heure une personne lira-t-elle l’avis, et pour quand le correctif sera-t-il en ligne ? “Dans le cadre de notre SLA standard” ne répond pas à cette question.

Comment Drupal note le risque, et ce que cela doit faire à votre contrat

Chaque avis Drupal porte un chiffre, et ce chiffre est l’outil de rédaction contractuelle le plus sous-utilisé de la plateforme. Drupal note les vulnérabilités avec le NIST Common Misuse Scoring System, NISTIR 7864 , produisant une note de 0 à 25 sur six critères : complexité d’accès, authentification, impact sur la confidentialité, impact sur l’intégrité, disponibilité d’un exploit et diffusion de la cible.

La note correspond à cinq libellés publiés. Une note de 0 à 4 est Not Critical, 5 à 9 est Less Critical, 10 à 14 est Moderately Critical, 15 à 19 est Critical, et 20 à 25 est Highly Critical. Ces paliers sont publics, stables et non interprétables par l’une ou l’autre partie.

Ils formeraient donc la colonne vertébrale naturelle d’un SLA de support, et presque personne ne s’en sert. Plutôt que d’inventer des définitions privées de gravité qu’un prestataire pourra contester plus tard, écrivez l’engagement de réponse directement contre la note Drupal : Highly Critical corrigé sous un nombre d’heures indiqué, hors heures ouvrées comprises, Critical sous un jour ouvré, Moderately Critical au cycle planifié suivant, le reste groupé. Aucune partie ne peut rediscuter ce que voulait dire “urgent”, puisqu’un tiers en a déjà décidé.

Highly Critical est un événement opérationnel différent

Les versions de sécurité Highly Critical du cœur sont rares, et Drupal les traite à part. L’équipe de sécurité publie à l’avance une annonce de service public pour que les propriétaires de sites organisent une permanence. PSA-2026-05-18 a fait exactement cela, avertissant le 18 mai 2026 d’une version hautement critique du cœur prévue pour le mercredi 20 mai et touchant toutes les branches maintenues.

Ce préavis est ce autour de quoi votre forfait doit être construit, car il transforme une urgence en rendez-vous. Un prestataire qui connaît l’annonce le lundi et garde un créneau de déploiement pour le mercredi fait tourner un service de support. Un prestataire qui l’apprend le jeudi fait tourner une liste de diffusion.

Il existe aussi une mesure d’atténuation à connaître. Drupal Steward est un pare-feu applicatif payant et réparti mondialement, exploité par la Drupal Association et l’équipe de sécurité, qui fournit un correctif virtuel au niveau réseau pour les failles hautement critiques du cœur, de sorte qu’un site reste protégé pendant que la mise à jour est testée. Les tarifs sont publiés en dollars américains et suivent le trafic : moins de 20 dollars par mois pour un site servant environ 1 million de requêtes HTTP, moins de 100 dollars par mois au-delà de 10 millions. Cela achète du temps, pas l’immunité, et un bon forfait dit qui paie.

Ce que la politique des avis de sécurité ne couvre pas

Trois exclusions de la politique de processus et de permissions des avis de sécurité changent ce qu’un forfait doit faire, et la plupart des contrats de support sont muets sur les trois.

Les avis ne sont émis que pour les versions stables. Si un module de votre site tourne en version alpha, bêta, release candidate ou dev, aucun avis ne sera jamais publié pour lui, et l’absence de nouvelles ne veut rien dire. La couverture se fait aussi projet par projet, sur adhésion volontaire et non par défaut, donc un module contribué non couvert peut porter une faille connue sans aucun canal de notification.

Puis vient celle qui piège tout le monde : aucun avis n’est émis pour les bibliothèques externes, même quand un projet contribué vous impose d’en installer une. Une bibliothèque JavaScript ou PHP tirée comme dépendance est votre problème, suivi par vous, et elle n’apparaîtra pas dans le flux Drupal.

La couverture peut aussi être retirée

La couverture de sécurité n’est pas permanente. PSA-2026-07-22 a retiré la couverture au module QA Accounts au motif qu’il privilégie la facilité d’usage sur la sécurité et ne vise que des sites inaccessibles depuis internet.

Voilà la forme du risque. Un module installé il y a des années sous couverture peut la perdre en silence, et rien sur votre site ne change pour vous le dire. Tenir un inventaire de chaque projet installé avec son statut de couverture et sa stabilité de version est un vrai travail récurrent, et il a sa place noir sur blanc dans le forfait.

Les montées de version de dépendances et de plateforme sont du support

Le poste le plus souvent exclu d’un contrat de support Drupal est celui qui décide à terme de la survie du site. Les exigences de plateforme de Drupal bougent, et elles bougent par paliers qui demandent un changement d’hébergement plutôt qu’un composer update.

Côté PHP, Drupal 10 exige au moins PHP 8.1 , tandis que Drupal 11 impose PHP 8.3 au minimum depuis la 11.1. La prise en charge de PHP 8.5 est arrivée dans Drupal 11.3, et Drupal 12.0 ne prend en charge que PHP 8.5. Ce dernier détail pèse plus lourd qu’il n’y paraît : un site confortablement installé sur PHP 8.1 aujourd’hui est à deux changements de plateforme forcés de Drupal 12.

Les exigences de base de données ont bougé tout autant. Drupal 11 réclame MySQL 8.0 ou plus récent, MariaDB 10.6 ou plus récent, PostgreSQL 16 ou plus récent, ou SQLite 3.45 ou plus récent. Drupal 10 acceptait MySQL 5.7.8, MariaDB 10.3.7 et PostgreSQL 12. Un hébergeur infogéré encore sur MySQL 5.7 est un blocage sur le chemin de mise à niveau, pas un détail, et notre note sur ce qui fait vraiment tourner Drupal dit vers quoi migrer.

La fin de vie de Drupal 10 est déjà un problème de forfait

Drupal 10 atteint sa fin de vie le 9 décembre 2026 , et Drupal 12 sort la même semaine, à partir du 7 décembre 2026. Le support de sécurité des branches 11.3.x et 10.6.x s’arrête au même moment. En septembre 2026, les branches qui reçoivent des versions de sécurité sont 11.4.x, 11.3.x et 10.6.x.

Lu contre le calendrier, cela fait environ trois mois. Tout site Drupal 10 sans plan de mise à niveau chiffré en septembre 2026 passera décembre soit à payer une prime d’urgence, soit à tourner sans support, et la seconde option devrait être une décision assumée plutôt qu’une dérive.

Un forfait qui vaut son prix devrait déjà avoir produit quatre choses : un rapport d’état de mise à niveau, une analyse du code déprécié des modules sur mesure et du thème, un contrôle de compatibilité de chaque module contribué avec Drupal 11 et 12, et un chiffrage écrit. Si votre prestataire n’a rien produit de tout cela, c’est là le constat. Notre décomposition des coûts, options et échéances de migration Drupal expose ce que le travail implique, et la même planification figure dans nos missions de développement de sites web .

Les sauvegardes ne valent rien tant qu’une restauration n’est pas testée

Presque tous les contrats de support Drupal promettent des sauvegardes. Très peu promettent une restauration, et cette distinction fait toute la valeur de la ligne. Le NCSC le dit clairement dans son guide pour les petites structures : une fois la sauvegarde faite , il faut savoir la restaurer et vérifier qu’elle contient tout ce qui compte.

Une restauration Drupal a trois pièces mobiles, et les sauvegardes partielles échouent sur la deuxième avec une régularité navrante. Il vous faut la base de données, les répertoires de fichiers publics et privés, et la configuration. Une sauvegarde qui prend la base mais pas le répertoire de fichiers restaure un site au contenu intact et sans images, ce qui ressemble à un site fonctionnel pour un script de surveillance et à une catastrophe pour un client.

Demandez un test de restauration daté, effectué dans un environnement jetable, avec une note écrite de sa durée et de ce qui manquait. Une fois par trimestre est une fréquence raisonnable pour la plupart des sites. Si un prestataire n’en a jamais fait, il ignore son propre délai de reprise, et vous aussi.

Surveillance de la disponibilité et des erreurs, et ce que la disponibilité mesure vraiment

Il y a un large écart entre un serveur qui répond et un site qui marche, et Drupal loge en plein dedans. Une erreur fatale PHP, une limite de mémoire épuisée, une connexion à la base qui échoue ou une reconstruction de cache cassée produisent toutes une page qu’un contrôle naïf lit comme un succès, ou un simple 500 que personne ne guette.

Une surveillance mesurée au serveur vous dit que la machine répond. Une surveillance mesurée à l’application demande une vraie page, suit les redirections et vérifie que le contenu attendu figure dans la réponse. Ce sont deux produits différents à deux prix différents, et une proposition qui dit “surveillance de disponibilité” sans préciser lequel décrit le moins cher des deux.

En dessous se trouve le journal de Drupal. Le rapport des messages récents et le journal d’erreurs PHP sont l’endroit où un cron qui échoue, une fonction dépréciée ou un module qui lève des exceptions à chaque requête apparaîtront bien avant qu’un visiteur ne se plaigne. Quelqu’un doit les lire régulièrement. Notre article sur les SLA de disponibilité qui veulent dire quelque chose explique comment les pourcentages se traduisent en minutes autorisées.

Lire un SLA de support Drupal avec un oeil critique

La plupart des SLA de support sont écrits pour être signés plutôt que pour servir, et ils sont signés parce qu’ils sont lus vite. Trois clauses portent presque tout le poids, et les lire attentivement prend dix minutes.

Le délai de réponse n’est pas le délai de résolution

Un SLA qui promet une réponse en deux heures promet en général que quelqu’un accusera réception du ticket en deux heures. Il ne promet pas que quiconque regarde votre site. Les prestataires sérieux s’engagent sur un objectif de résolution, ou au minimum sur un objectif de diagnostic et de contournement, le délai de correction étant indiqué séparément.

Là où le travail ne peut honnêtement pas être borné dans le temps, un contrat sincère le dit et s’engage plutôt à un effort continu jusqu’à résolution. Cela, c’est un vrai engagement. “Réponse en deux heures” tout seul est l’engagement d’envoyer un courriel.

Les définitions de gravité décident de tout

Tout SLA a une grille de gravité, et c’est en général le prestataire qui attribue la gravité. Voilà la faille. Si la définition de Priorité 1 est “site indisponible”, alors un paiement qui échoue pour un tiers des clients est en Priorité 3 et sera regardé la semaine prochaine.

Écrivez les définitions autour de l’impact métier plutôt que de l’état technique, et mettez des exemples concrets au contrat : une étape de paiement en échec, une connexion administrateur impossible, un formulaire de contact cassé sur la page de demande. Convenez ensuite de qui attribue la gravité et comment vous contestez une attribution.

Les heures de couverture ne sont pas les heures ouvrées

“Heures ouvrées” et “couverture” désignent deux choses et sont souvent employés l’un pour l’autre. La couverture est la période pendant laquelle le chronomètre tourne et où quelqu’un est tenu d’agir. Si la couverture va de 09:00 à 17:30 les jours ouvrés, un avis publié à 1700 UTC un mercredi de décembre sera repris le lendemain matin au mieux.

Pour Drupal en particulier, notez que la fenêtre de sécurité du cœur s’ouvre à 1600 ou 1700 UTC. Un prestataire britannique dont la couverture s’arrête à 17:30 se tient structurellement à sa limite, donc les dispositions hors heures ouvrées pour les avis Highly Critical doivent être nommées à part et chiffrées.

Ce qui compte comme incident, et ce qui est exclu

La section des exclusions est l’endroit où un forfait devient discrètement moins cher qu’il n’en a l’air. Les exclusions courantes sont tout à fait raisonnables isolément et déraisonnables ensemble : pannes d’un hébergeur tiers, problèmes causés par le personnel du client, défauts dans des modules non installés par le prestataire, tout ce qui touche à un thème payant, et tout ce que le prestataire classe en changement plutôt qu’en panne.

Ce dernier point est le tranchant. Si une correction de bogue exige une modification de configuration, et que les modifications de configuration sont facturables, alors presque toute panne peut être reclassée dans la colonne facturable. Demandez directement comment le prestataire distingue une panne d’un changement, et demandez deux exemples de chaque tirés de son travail récent.

Vérifiez aussi ce qui se passe avec les tiers. Quand la passerelle de paiement, le connecteur CRM ou l’hébergeur est en cause, le prestataire coordonne-t-il la correction, ou le ticket se ferme-t-il comme hors périmètre ? La coordination est un vrai travail qui mérite d’être payé, mais seulement si le contrat dit qu’elle a lieu.

Les trois modèles de forfait, comparés honnêtement

Presque tout arrangement de support Drupal prend une de trois formes, et chacune répond correctement à une situation différente. L’erreur est d’acheter une forme en attendant le comportement d’une autre.

Un volume d’heures fixe par mois

Vous achetez un bloc d’heures, disons 8 ou 16, et le prestataire les applique à ce que vous demandez. C’est transparent, facile à comparer entre devis, et cela convient à une organisation avec un filet régulier de petits changements et quelqu’un en interne capable de les prioriser.

Sa faiblesse est que la maintenance concurrence les nouveautés sur la même enveloppe. Dans un mois chargé, les correctifs de sécurité perdent en silence face à la page d’atterrissage d’une campagne, parce que la personne qui dépense les heures a une échéance et que le correctif n’en est pas une. Si vous achetez ce modèle, réservez une part des heures à la maintenance dans le contrat lui-même.

Corrections illimitées et changements sur devis

Le prestataire absorbe la maintenance et les petites corrections pour un forfait mensuel fixe, et tout ce qui dépasse un seuil convenu est chiffré à part. C’est le modèle que la plupart des agences poussent, et pour un site stable avec un propriétaire inquiet c’est vraiment la bonne réponse, car il convertit un risque variable en une ligne fixe au budget.

Sa faiblesse est la frontière. “Petite correction” reste indéfini jusqu’à ce que quelqu’un en ait besoin, et le seuil bouge selon la tournure du mois. Exigez une définition écrite, idéalement une limite de temps comme tout ce qui fait moins de 30 minutes, et un rapport mensuel montrant ce qui a été absorbé.

Régie pure

Pas de forfait, un tarif journalier, et du travail quand vous le demandez. C’est le choix honnête pour un site peu risqué dont le propriétaire suivra vraiment les mises à jour, et pour les organisations disposant de compétences internes qui ont besoin d’une aide spécialisée ponctuelle plutôt que d’une permanence.

Sa faiblesse est que rien de proactif n’arrive jamais, puisque personne n’est payé pour regarder. La régie fait aussi mauvaise file d’attente : vous concurrencez des clients sous forfait pour les mêmes ingénieurs, donc un mauvais jour la réponse se mesure en semaines plutôt qu’en heures.

Le problème d’incitation du support non décompté

Le support non décompté a un défaut structurel dont personne dans le métier n’aime parler. Si le prestataire est payé pareil quel que soit le nombre d’heures qu’un site consomme, alors chaque heure passée sur votre site réduit sa marge, et le comportement commercialement rationnel est d’en passer le moins possible.

Cela ne se voit généralement pas comme de la négligence. Cela se voit comme une préférence pour la correction rapide plutôt que juste, pour l’étouffement d’un symptôme plutôt que la recherche d’une cause, et pour le report de la montée de version d’un module qui coûterait une journée de tests de régression. Cela se voit aussi en sens inverse sur les offres bon marché, où le tarif ne tient que si le site n’est réellement jamais touché.

Le contrepoids est une obligation de compte rendu. Un rapport mensuel listant les heures consommées, les mises à jour appliquées, les avis évalués et les tickets clos rend la consommation visible des deux côtés, et fait d’un compte non rentable une conversation plutôt qu’une lente dégradation du service. Tout prestataire confiant dans son modèle l’acceptera. Un prestataire qui résiste vous dit à quoi sert vraiment le modèle.

À quoi ressemble le bon travail sur le plan opérationnel

Trois pratiques techniques séparent un prestataire Drupal capable de tenir votre site en sécurité de celui qui improvise. Aucune n’est exotique, et on peut interroger les trois facilement.

Composer, ou rien

La documentation de Drupal est catégorique sur le mélange des méthodes de mise à jour et prévient que des sites peuvent rencontrer des problèmes critiques si les mises à jour Composer sont combinées à d’autres approches, et qu’une fois que Composer gère un module il doit aussi gérer le cœur. Un prestataire qui téléverse encore des dossiers de modules par FTP finira par supprimer un répertoire vendor dont dépendait un module contribué.

Demandez si composer.json et composer.lock sont en gestion de version, et si Composer tourne en production ou si l’artefact construit est déployé. Les deux réponses peuvent être bonnes. Ne pas avoir de réponse ne peut pas l’être.

Une préproduction identique à la production

Une préproduction avec une autre version de PHP, une autre version de base de données ou un autre jeu de modules ne teste rien d’utile. Le but d’une préproduction est de laisser un correctif de sécurité échouer là où cela ne coûte pas d’argent, et elle n’y parvient que si les deux environnements coïncident sur les axes qui cassent.

Demandez comment la préproduction est rafraîchie depuis la production, à quelle fréquence, et si elle contient une copie anonymisée du contenu réel. Une préproduction avec trois nœuds de test ne révélera pas la mise à jour qui casse une vue portant sur 40 000 lignes.

La configuration en gestion de version

Drupal garde par défaut la configuration dans la base de données , et le système de gestion de configuration existe pour l’exporter vers des fichiers que l’on peut committer, relire et importer dans un autre environnement. Une équipe qui s’en sert peut reproduire les réglages du site de façon déterministe. Une équipe qui ne s’en sert pas clique dans les écrans d’administration en production et espère.

C’est le signal le plus net d’une conversation avec un prestataire. Demandez comment un changement fait en préproduction atteint la production. Si la réponse est une description plutôt qu’un silence, le reste de la conversation se passe en général bien.

S’ils ne savent pas décrire le déploiement, la réponse est là

Il n’y a pas de manière polie de le dire. Un prestataire incapable de décrire, en une minute posée, comment le code passe du poste d’un développeur à votre site en ligne vous dit que les déploiements sont improvisés. Les déploiements improvisés sont la raison pour laquelle les correctifs de sécurité tardent : personne ne veut lancer la procédure manuelle risquée un mercredi soir.

La clause de réversibilité que personne ne lit

Un jour vous changerez de prestataire, et la clause qui régit ce moment est écrite pendant que tout le monde est aimable et lue quand plus personne ne l’est. Elle doit dire quatre choses clairement.

À qui appartient le code, modules sur mesure et travail de thème compris, et sous quelle licence. Où vit le dépôt et comment l’accès est transféré. Qu’un export complet de la base, des fichiers et de la configuration sera fourni dans un format indiqué sous un nombre de jours ouvrés indiqué. Et que le DNS, l’hébergement et les identifiants des services tiers sont remis plutôt que gardés.

Le mode d’échec n’est généralement pas la malveillance. C’est un prestataire qui héberge votre site sur son propre compte, détient l’unique copie du dépôt, et met six semaines à répondre parce que vous n’êtes plus client payant. Demandez la clause de réversibilité avant de signer, et traitez toute réticence comme une information.

Drupal 7 : fin de vie, support étendu et l’écart entre les deux

Le support de sécurité de Drupal 7 a pris fin le 5 janvier 2025 . La communauté a cessé de produire des correctifs, et l’énorme écosystème de modules contribués qui faisait l’utilité de Drupal 7 a cessé d’être maintenu en même temps.

La Drupal Association gère un Extended Security Support Provider Program, et HeroDevs et Tag1 Consulting en sont les prestataires certifiés. Acheter ce support est une décision légitime pour une organisation qui ne peut vraiment pas migrer cette année, et cela vaut nettement mieux que rien.

Ce que cela ne fait pas, c’est rendre le site sûr au sens ordinaire. Un prestataire commercial corrige les failles qu’il trouve ou qu’on lui signale, selon son propre calendrier, pour le parc de modules qu’il a accepté de couvrir. Il ne rétablit pas le processus public d’avis, il ne couvre pas tous les modules contribués que vous avez installés, et il ne s’étend pas aux bibliothèques externes dont ces modules dépendent. Le support étendu est une façon maîtrisée de faire tourner une plateforme non maintenue, et un contrat de support n’est pas synonyme de sécurité.

Si vous êtes sur Drupal 7 en septembre 2026, le conseil honnête est de mettre l’argent dans la migration plutôt que dans une location. Notre guide 2026 du développement web Drupal décrit la plateforme telle qu’elle est, et le détail du processus d’avis figure dans notre note sur la sécurité Drupal, les avis et le risque réel .

Le support éditorial et le budget de changement

Deux postes sont chassés des contrats de support parce qu’ils sont difficiles à borner, et ce sont justement ceux que les clients remarquent.

Le support éditorial, c’est quelqu’un capable d’ajouter un type de contenu, de réparer une vue qui ne filtre plus correctement, de reformer un rédacteur après un départ, ou de comprendre pourquoi un style d’image coupe les visages. C’est peu spectaculaire et très fréquent, et un forfait sans cela produit un client qui cesse de demander et se met à contourner le site.

Le budget de changement est l’autre moitié. Tout site accumule une file de petits travaux : un champ dans un formulaire, une redirection après le déplacement d’une page, un changement de destinataire des demandes. Nommer une enveloppe mensuelle en heures pour cette file empêche qu’elle ne devienne un projet d’urgence trimestriel. Deux à quatre heures par mois est réaliste pour un petit site, 8 à 16 pour un site actif.

Ce que coûte le support Drupal au Royaume-Uni

Les chiffres ci-dessous sont nos estimations maison pour 2026, fondées sur le travail des agences britanniques et non sur une enquête publiée. Ils supposent un prestataire faisant les huit activités décrites plus haut, pas un abonnement de surveillance avec une boîte de support.

En clair : un petit site vitrine se situe autour de £250 à £600 par mois, ce qui achète la surveillance des avis, un cycle mensuel de correctifs, la vérification des sauvegardes et une heure ou deux de changements. Un site moyen avec des intégrations tourne autour de £700 à £1,800, car chaque intégration ajoute une surface de régression à retester après chaque mise à jour du cœur. Un site complexe ou multilingue avec des modules sur mesure démarre vers £2,000 et atteint £6,000 ou plus.

Les formules de surveillance seule, où le prestataire suit les avis et vous dit ce qui s’applique sans rien déployer, se situent plus bas, autour de £250 à £450 par mois. Face aux tarifs journaliers des agences britanniques, de £600 à £900, un forfait de £1,500 achète environ deux journées d’ingénieur. Le détail des tarifs est dans notre note sur les tarifs, compétences et sélection d’un développeur Drupal , et la vue budgétaire plus large dans le coût de la maintenance logicielle .

Ce qui fait passer un site d’une fourchette à la suivante

L’instinct est de tarifer le support au trafic, et le trafic est presque sans rapport. Un site qui sert 200 000 visites par mois avec vingt modules et sans intégration coûte moins cher à soutenir qu’un site qui en sert deux mille avec un connecteur CRM, une passerelle de paiement et une migration sur mesure.

Trois choses pilotent réellement le coût. Le nombre de modules, car chaque module contribué est un flux d’avis à surveiller et un risque de compatibilité à chaque mise à jour du cœur. Le nombre d’intégrations, car chacune est un contrat externe qui peut changer sous vos pieds et un test de régression à relancer. Et le volume éditorial, car une équipe active génère à rythme constant des questions de support, des changements de droits et des retouches du modèle de contenu.

Le code sur mesure est le multiplicateur des trois. Un site avec 12 000 lignes de code de modules maison exige une analyse des dépréciations et une passe de régression à chaque version mineure, soit une journée de travail qu’un site purement contribué n’a pas. C’est de là que vient la fourchette haute, et c’est le travail que nos missions de développement logiciel sont le plus souvent appelées à absorber.

Questions à poser à un prestataire potentiel

Six questions, et les réponses qui doivent vous inquiéter.

Sur quelle version de Drupal et de PHP notre site tourne-t-il aujourd’hui, et quel est le chemin de mise à niveau ? Une réponse qui exige d’aller vérifier convient. Une réponse qui arrive une semaine plus tard, non. Comment découvrez-vous qu’un avis de sécurité nous concerne ? “Nous surveillons drupal.org” est faible ; un inventaire de modules par site est la réponse attendue.

Décrivez-moi votre processus de déploiement. Une hésitation ici est le signal négatif le plus fort de toute la conversation. Quand avez-vous restauré ce site depuis une sauvegarde pour la dernière fois ? “Nous faisons des sauvegardes quotidiennes” ne répond pas à la question. Qu’est-ce qui est exclu du forfait, et comment décidez-vous si quelque chose est une panne ou un changement ? Et enfin : si nous partons, que recevons-nous et sous quel délai ?

Ce qui arrive quand il n’y a pas de forfait

C’est une séquence plutôt qu’un avertissement, et elle se déroule au même rythme sur tout site Drupal sans support.

Les premiers mois, rien ne se passe, et c’est le problème, car cela apprend à tout le monde que rien n’a besoin de se passer. Quelque part entre le sixième et le douzième mois, l’arriéré de mises à jour franchit le point où elles cessent d’être sûres une par une, parce qu’un module réclame désormais un cœur plus récent, qui réclame un PHP plus récent, que l’hébergeur ne propose pas. Appliquer un correctif est devenu un projet.

Puis le site sort complètement du support de la plateforme, et un changement de navigateur ou de PHP casse quelque chose de visible. La réparation commence maintenant par une mise à niveau que personne n’a budgétée, chiffrée en travail d’urgence, et les parties du site sans documentation sont reconstruites plutôt que réparées. Si une violation survient en chemin et que des données personnelles sont concernées, l’ICO attend une notification sous 72 heures après en avoir eu connaissance lorsqu’elle risque de porter atteinte aux droits et libertés des personnes, une échéance que l’on tient avec des journaux et des sauvegardes que l’on a ou que l’on n’a pas.

La facture de reprise vaut invariablement plusieurs fois le forfait qui l’aurait évitée, et la différence n’est pas la main d’oeuvre. C’est que le travail planifié a lieu un mardi avec un plan de retour arrière, et le travail d’urgence un dimanche sans.

Cadrer le périmètre avant de signer

Le but de tout ceci n’est pas de vous rendre méfiant envers les prestataires. C’est de rendre la comparaison entre deux propositions signifiante, car aujourd’hui la plupart des devis de support Drupal sont incomparables par construction : des mots différents, des exclusions différentes, et aucune définition partagée du travail mensuel.

Prenez les huit activités, les paliers de risque Drupal, les trois modèles de forfait et les six questions, et confrontez-les à ce qui est sur votre bureau. Ce qui survit à cela est une vraie proposition.

Mecanik accompagne des sites Drupal dans le cadre de son travail de développement de sites web et de développement logiciel , et la première mission est le plus souvent un inventaire plutôt qu’une réparation, car la plupart des sites qui arrivent chez nous ne savent pas dire lesquels de leurs modules sont encore couverts par le flux des avis de sécurité .

Questions fréquentes

Que doit contenir un forfait de support Drupal ? Huit activités : la surveillance des avis de sécurité contre votre parc exact de modules, les mises à jour du cœur et des modules contribués selon un cycle défini, les montées de version des dépendances et de la plateforme PHP, la vérification des sauvegardes avec restaurations testées, la surveillance de la disponibilité et des erreurs applicatives, le contrôle des régressions de performance, le support éditorial et un budget de changement nommé en heures. Un contrat qui n’en nomme que quatre est incomplet, et les quatre qui manquent d’ordinaire sont les tests de restauration, les contrôles de performance, les montées de version de plateforme et le budget de changement.

Combien coûte le support Drupal par mois au Royaume-Uni ? En estimation maison pour 2026, un petit site vitrine revient à environ £250 à £600 par mois, un site moyen avec une ou deux intégrations à £700 à £1,800, et un site complexe multilingue avec des modules sur mesure à £2,000 à £6,000. Les formules de surveillance seule se situent autour de £250 à £450. Face aux tarifs journaliers des agences britanniques de £600 à £900, un forfait de £1,500 achète environ deux journées d’ingénieur.

Quand Drupal publie-t-il ses correctifs de sécurité ? Les versions de sécurité du cœur de Drupal sortent dans une fenêtre le troisième mercredi du mois, à partir de 1200 America/New York, soit 1600 ou 1700 UTC selon la saison. Les projets contribués disposent d’une fenêtre de sécurité chaque mercredi. Les versions hautement critiques du cœur sont précédées d’une annonce de service public pour que les propriétaires de sites organisent une permanence à l’avance.

Le support étendu de Drupal 7 équivaut-il à être en sécurité ? Non. Le support de sécurité de Drupal 7 a pris fin le 5 janvier 2025, et la Drupal Association certifie HeroDevs et Tag1 Consulting dans le cadre de son Extended Security Support Provider Program. Ces prestataires corrigent ce qu’ils couvrent, selon leur propre calendrier, pour un parc de modules convenu. Cela ne rétablit pas le processus public d’avis, ne couvre pas tous les modules contribués installés et ne s’étend pas aux bibliothèques externes.

Quand Drupal 10 atteint-il sa fin de vie ? Drupal 10 atteint sa fin de vie le 9 décembre 2026, la semaine même où sort Drupal 12, à partir du 7 décembre 2026. Le support de sécurité des branches 11.3.x et 10.6.x s’arrête au même moment. Drupal 12 ne prend en charge que PHP 8.5, donc les sites sur des versions de PHP plus anciennes ont besoin d’un changement d’hébergement avant la mise à niveau, pas après.