Budget de plateforme web : le construire et le défendre

Il est plus facile de justifier le budget d’une plateforme web lorsque le service financier peut voir à quoi correspond chaque ligne. Certains coûts permettent d’assurer le fonctionnement de la plateforme. D’autres sont liés à une échéance ou à une obligation. Le reste correspond à des dépenses que l’entreprise peut choisir de financer ou de reporter à plus tard, et chaque chiffre doit s’appuyer sur une hypothèse clairement énoncée. La période de budgétisation rend cette discipline indispensable. Dans l’enquête de Forrester sur la planification pour 2027, menée auprès de plus de 2 600 décideurs commerciaux et technologiques, 82 % des décideurs technologiques s’attendent à des augmentations budgétaires en 2027, votre demande se retrouve donc aux côtés de nombreuses autres sollicitant des moyens supplémentaires. Une demande qui se résume à une seule ligne, « plateforme web, plus un pourcentage », ne donne au directeur financier que peu d’éléments à approuver, si ce n’est un certain niveau de confiance. Cette approche est conçue pour le cycle de planification de septembre à novembre. Elle part de la base de référence de 2026 et aboutit aux personnes qui doivent approuver le budget.

Ce guide s'adresse au directeur technique (CTO), au responsable du numérique, au directeur informatique ou au fondateur technique qui gère une plateforme web en contact direct avec la clientèle. Cela englobe le site ou l'application, le CMS ou le framework sur lequel elle repose, l'hébergement, les intégrations, ainsi que les personnes ou l'agence chargées de sa mise à jour. Il ne présuppose aucune pile technologique particulière, et chaque étape peut être réalisée avec l'équipe dont vous disposez déjà ou confiée à n'importe quelle agence de renom, y compris Keroberos. L’objectif est d’aboutir à un budget que vous pouvez présenter en une seule réunion, avec des chiffres qu’un partenaire financier peut retracer jusqu’à une facture ou une date.

Points clés à retenir

• Commencez par les chiffres réels de 2026 et reconstituez-les pour obtenir une base de référence unique. Il ne suffit pas d’ajouter simplement un pourcentage au budget de l’année dernière.
• Distinguez les coûts opérationnels, les travaux obligatoires et les projets discrétionnaires. Cela permet de distinguer clairement les postes budgétaires négociables de ceux qui ne peuvent être que reportés.
• Tout chiffre ne provenant pas d’une facture doit figurer dans un registre des hypothèses, avec indication de la source, du responsable et d’une fourchette.
• Expliquez le retour sur investissement ligne par ligne en utilisant les termes déjà employés par le service financier, et présentez les conséquences de chaque réduction possible avant même que quiconque ne la demande.

Pourquoi le budget d'une plateforme sera remis en question en 2027

Le cycle de planification 2027 est soumis à deux pressions contradictoires. Les budgets devraient augmenter, et Forrester a constaté que près d'un quart des dirigeants prévoient une croissance de 10 % ou plus. L'étude « Global Technology Leadership Study » 2026 de Deloitte décrit la contre-pression : les dépenses technologiques ne devraient augmenter que modestement et les dirigeants sont contraints de faire des compromis difficiles.

Les plateformes web se trouvent pris en étau entre ces deux pressions, en partie parce que leurs coûts sont répartis entre plusieurs budgets. L’hébergement peut figurer dans une ligne budgétaire dédiée à l’infrastructure, les licences dans une ligne dédiée aux logiciels, les heures facturées par les agences dans une ligne dédiée au marketing ou aux projets, et le temps consacré en interne ne figure dans aucun budget. Aucun responsable unique n’a une vue d’ensemble, si bien que la plateforme est rarement évaluée comme un tout. La première étape consiste à regrouper ces coûts.

Étape 1 : reconstituer la référence budgétaire de 2026 en tant que plateforme unique

Commencez par les factures et les imputations salariales des douze derniers mois, et mettez de côté le budget de l’année dernière. Le budget indique ce que vous aviez prévu de dépenser ; la comptabilité générale indique ce que vous avez réellement dépensé. Commencez par cette dernière. Demandez les chiffres réels par fournisseur et par centre de coûts, dressez la liste de tous les fournisseurs impliqués dans la plateforme et attribuez-en un à chaque catégorie. Les coûts partagés, tels qu’un compte cloud hébergeant également d’autres systèmes ou un développeur qui répartit son temps entre plusieurs produits, nécessitent une règle de répartition indiquée à côté du montant.

Une fois la base de référence réétablie, deux chiffres sont importants : le montant total des dépenses et leur répartition par catégorie. Si le total du grand livre diffère du budget de l’année dernière, signalez cette différence et expliquez-la dans le document final. Pour le poste « maintenance », la liste de contrôle figurant dans notre guide sur ce que couvre un contrat de support adéquat vous aide à identifier ce qui est inclus et ce qui est facturé en supplément. Évaluez-le en fonction des tâches et des heures prévues dans votre propre contrat, car les règles empiriques basées sur un pourcentage du coût de construction ne reposent sur aucune source fiable.

Étape 2 : distinguer les dépenses opérationnelles, obligatoires et discrétionnaires

Commencez par distinguer les coûts opérationnels, les tâches obligatoires et les projets discrétionnaires. Cette distinction permet au service financier de voir quels postes peuvent être négociés et lesquels ne peuvent qu’être reportés. Les dépenses opérationnelles permettent de maintenir la plateforme à son niveau de service actuel, notamment l’hébergement, l’assistance et les licences au volume actuel. Les dépenses obligatoires sont liées à une échéance ou à une obligation, comme la fin du support d’une version, l’entrée en vigueur d’une réglementation ou le renouvellement d’un contrat à un prix plus élevé. Les dépenses discrétionnaires couvrent les travaux que l’entreprise peut choisir de reporter sans mettre en péril la plateforme existante : nouvelles fonctionnalités, refonte, réduction de la dette technique ou expérimentations.

Cette distinction s’apparente au cadre « run, grow et transform » utilisé dans les budgets technologiques des entreprises. L’étude de Deloitte de 2026 rappelle que les responsables technologiques ont déclaré consacrer 48 % de leur budget aux activités de « fonctionnement » en 2023, 31 % à la « croissance » et 21 % à la « transformation », un chiffre issu de l’étude de Deloitte de 2023, et indique que 2026 marque le premier glissement vers une répartition plus équilibrée. Des répartitions en pourcentage telles que 60/25/15 ou 70/20/10 circulent dans les modèles de budget sans source principale ; il est donc préférable de suivre votre propre ratio d’une année à l’autre.

Le calendrier des dépenses obligatoires

Commencez par traiter les coûts obligatoires. Ceux-ci déterminent le montant minimum dont la plateforme a besoin avant que vous ne décidiez des autres postes à financer. La plupart de ces coûts proviennent de trois sources : les dates de fin de support, les exigences réglementaires et les contrats. Le fait qu’un framework ou un moteur d’exécution arrive en fin de support n’empêche pas votre site de fonctionner du jour au lendemain. Le problème est que les correctifs de sécurité ne sont plus fournis par les responsables du projet ; par conséquent, toute vulnérabilité découverte par la suite sera à votre charge. Les dates ci-dessous proviennent de la documentation propre à chaque projet, et le travail qu’elles impliquent augmente avec le nombre de versions de retard que vous accumulez.

Plusieurs composants largement utilisés arriveront en fin de prise en charge avant la fin de l'année 2026. Python 3.10 est prévu pour octobre, .NET 8 (LTS) et .NET 9 suivront en novembre, et Drupal 10 arrivera en fin de vie le 9 décembre, un cas que notre guide de migration traite en détail. PHP 8.2 ne bénéficiera plus de support de sécurité à compter du 31 décembre. Les dates pour 2027 sont les suivantes : Node.js 22 le 30 avril, Python 3.11 en octobre (prévu) et PHP 8.3 le 31 décembre.

Prenons l’exemple d’un site fictif fonctionnant sous Drupal 10 sur PHP 8.2 avec une application front-end utilisant Node.js 22 : trois dates de fin de support tombent juste avant ou pendant l’exercice budgétaire 2027. Chacune d’entre elles devient une ligne obligatoire, accompagnée de sa date et d’une estimation fournie par l’équipe qui se chargera des travaux. Ensemble, ces dates définissent le budget minimum à prévoir avant même d’avoir choisi la moindre amélioration.

Vérifiez toutes les versions que vous utilisez, y compris celles de votre CMS, par rapport à ces dates, et ajoutez celles qui s'appliquent à votre pile technologique. Une plateforme sans calendrier fixe doit tout de même faire l’objet d’une ligne budgétaire, car un plugin ou un thème non pris en charge entraîne la même obligation, même en l’absence de date publiée.

La réglementation impose des obligations assorties de dates précises. Selon la Commission européenne, la loi européenne sur la cyber-résilience prévoit que ses obligations de déclaration s’appliquent à compter du 11 septembre 2026 et que ses principales obligations s’appliquent à compter du 11 décembre 2027. Elle s’applique aux produits comportant des éléments numériques. La loi européenne sur l’accessibilité s’applique aux produits et services mis sur le marché après le 28 juin 2025, y compris les boutiques en ligne. Si votre plateforme vend ou dessert le marché de l’UE, demandez à votre service juridique lesquelles de ces dispositions s’appliquent à votre plateforme et indiquez la réponse dans votre documentation budgétaire, avec la date correspondante.

Les contrats constituent la troisième source. Répertoriez chaque renouvellement prévu en 2027 en précisant son délai de préavis et son mécanisme de tarification, tels qu'ils figurent dans le contrat lui-même. Tout renouvellement pour lequel vous n'avez pas respecté le délai de préavis devient, par défaut, une dépense obligatoire.

Étape 3 : établir un registre des hypothèses

Une hypothèse correspond à tout chiffre figurant dans le budget qui ne provient pas d’une facture. Un registre répertorie chacune d’entre elles avec une valeur de référence, des fourchettes minimale et maximale, une source, un responsable et une date pour son prochain réexamen. Cela donne au service financier un élément concret à remettre en question : la donnée elle-même, plutôt que de se contenter de juger si le chiffre semble raisonnable ou non.

Quelques hypothèses suffisent généralement à expliquer la majeure partie de l’incertitude dans le budget d’une plateforme web. Pour le trafic et le volume de requêtes, utilisez douze mois de journaux CDN ou de serveurs, en distinguant les requêtes humaines des requêtes automatisées, car les coûts d’hébergement, de CDN et de services de sécurité dépendent du nombre de requêtes. Sur le réseau de Cloudflare, le trafic humain générait 47 % des requêtes HTML au 2 décembre 2025, et les bots non basés sur l’IA 44 % ; ainsi, un journal qui comptabilise chaque requête comme un visiteur surestime la demande.

Pour connaître les tarifs des fournisseurs, consultez vos devis de renouvellement et les clauses de vos contrats, car les prix restent rarement inchangés d’un renouvellement à l’autre. Les tarifs applicables au personnel et aux agences proviennent des barèmes en vigueur et de la planification salariale du service financier. L’évaluation de l’efficacité du cloud nécessite vos propres données d’utilisation et de facturation. À titre de comparaison, le rapport « State of the Cloud 2026 » de Flexera, fondé sur une enquête menée auprès de plus de 750 décideurs et utilisateurs du cloud, indique que les dépenses inutiles liées au cloud ont atteint 29 %, soit une première hausse en cinq ans.

Une entrée peut être succincte. Pour une ligne CDN mensuelle fictive, cela implique d’utiliser une base de référence tirée de douze mois de factures du fournisseur, ajustée en fonction de la part automatisée des requêtes, ainsi qu’un scénario bas et un scénario haut, le responsable de l’infrastructure en tant que propriétaire, et une date de révision. Le scénario haut repose sur une hypothèse plus éloignée de la situation actuelle, car le volume de requêtes peut fortement augmenter lors du lancement d’une campagne ou de l’arrivée d’un robot d’indexation, et un partenaire financier peut contester soit la fourchette, soit la source.

Deux pratiques s'avèrent particulièrement utiles ici. Privilégiez les fourchettes plutôt qu'une valeur unique, car un chiffre isolé sous-entend une certitude dont personne ne dispose. Notez également quelles hypothèses vous maîtrisez et lesquelles vous ne maîtrisez pas. C'est pour ce deuxième groupe que vous aurez besoin de l'avis du service financier avant la réunion.

Étape 4 : défendre le rendement en utilisant le langage du service financier

Le retour sur investissement doit être expliqué différemment selon l’objectif visé par la dépense. Les coûts évités sont plus faciles à justifier lorsqu’ils relèvent de la catégorie des dépenses obligatoires : la mise à niveau que vous financez aujourd’hui pour éviter une situation d’urgence que vous devriez financer plus tard. La protection ou la génération de revenus nécessite un lien traçable entre la plateforme et une ligne de chiffre d’affaires, et c’est le responsable de cette ligne qui doit faire valoir cet argument. La capacité libérée implique de compter les heures, et cela ne convainc que si quelqu’un s’engage sur l’utilisation qui sera faite de ces heures. La réduction des risques est plus difficile à quantifier ; par conséquent, si vous ne disposez pas d’un historique des incidents ni de chiffres sur l’exposition au risque, décrivez cette exposition en termes simples et évitez d’avancer une probabilité inventée.

Évitez d’indiquer un seul pourcentage de retour sur investissement (ROI) pour l’ensemble de la demande. Un chiffre unique peut masquer les éléments de la demande qui créent réellement de la valeur, tandis qu’un retour sur investissement indiqué par ligne, ou par groupe de lignes, peut être vérifié. Lorsqu’un bénéfice ne peut pas encore être mesuré, précisez-le et indiquez ce que vous mesurerez et dans quel délai.

Si le poste « discrétionnaire » comprend le remboursement de dettes, une évaluation de la dette technique fournit les éléments probants : elle met en évidence les indicateurs que l’entreprise suit déjà, classés par coût. Intégrez ce classement dans ce budget pour justifier des postes spécifiques.

Renseignez-vous dès que possible auprès du service financier sur la manière dont les dépenses de développement sont comptabilisées dans vos comptes, car la distinction entre les coûts capitalisés et les coûts passés en charges modifie la présentation d'une même demande. Selon les normes comptables américaines (US GAAP), la mise à jour des normes comptables Accounting Standards Update 2025-06 du FASB supprime le modèle par étapes de projet pour les logiciels à usage interne et y intègre les directives distinctes relatives aux coûts de développement de sites web, avec effet pour les exercices ouverts après le 15 décembre 2027. Les entreprises établissant leurs comptes selon les normes IFRS appliquent la norme IAS 38. Le traitement comptable dépend de la juridiction et de vos auditeurs ; il convient donc de considérer cette question comme un sujet à soumettre au service financier et non comme une conclusion à tirer vous-même.

Consacrez aux outils d’IA une ligne budgétaire distincte, avec un responsable désigné, un plafond de dépenses et une date de révision. L’étude de Deloitte de 2026 a révélé que 42 % des responsables technologiques interrogés font état d’un retour sur investissement faible, voire nul, en matière d’IA, ce qui constitue l’hypothèse de départ d’un partenaire financier face à toute nouvelle demande liée à l’IA. Les risques liés aux fonctionnalités d’IA sont abordés dans notre guide sur la sécurité des sites web à l’ère de l’IA, et les aspects liés à la visibilité dans notre guide sur la préparation de votre site web aux agents IA.

Étape 5 : montrer ce que coûterait une réduction budgétaire

Tôt ou tard, quelqu’un demandera où il est possible de réduire le budget. Un tableau de scénarios de coupes budgétaires permet de préparer la réponse à l’avance : pour chaque ligne, ce qui cesse de fonctionner, quand les conséquences se font sentir et ce qu’il en coûte pour revenir en arrière. Cela permet de centrer la discussion sur ce qui change réellement lorsqu’une ligne est supprimée, plutôt que sur un pourcentage arbitraire. Cela permet également de distinguer clairement les postes obligatoires des postes discrétionnaires.

À partir de là, vous pouvez présenter le budget à trois niveaux. Commencez par les dépenses minimales requises : les coûts opérationnels plus les travaux obligatoires. Ajoutez les postes discrétionnaires pour présenter le budget proposé. Si le total doit être revu à la baisse, dressez la liste des postes spécifiques qui seraient supprimés et précisez les conséquences de chacune de ces suppressions. Les postes obligatoires s’ajoutent au total ; ainsi, une demande de gel du budget implique que des postes discrétionnaires doivent être supprimés, en les citant nommément. Cela permet au directeur financier d’examiner un compromis précis plutôt qu’un chiffre arbitraire à supprimer.

Étape 6 : recenser les parties prenantes qui doivent donner leur accord

Un budget passe généralement entre les mains de plusieurs personnes, et chacune l’examinera sous un angle différent. Les pouvoirs de décision varient d’une organisation à l’autre ; commencez donc par vous demander, pour chaque ligne, qui peut donner son accord, qui peut opposer son refus et qui doit simplement être informé. Discutez avec ces personnes dans un ordre permettant à chaque échange de lever les questions avant de passer au suivant.

Commencez par le service financier. La suite de la discussion repose sur l’établissement d’une base de référence commune. Le service financier vérifie que les chiffres sont traçables : un total qui correspond au grand livre, des hypothèses accompagnées de leurs sources, ainsi que la répartition entre dépenses opérationnelles, obligatoires et discrétionnaires. Viennent ensuite les responsables des postes de recettes gérés par la plateforme, tels que le marketing, les ventes ou les produits. Leur rôle est d’expliquer, avec leurs propres mots, en quoi un poste discrétionnaire est lié à un objectif dont ils sont responsables, car cette explication a plus de poids lorsqu’elle émane du responsable de ce chiffre.

Les services de sécurité, juridique et de protection des données examinent les postes obligatoires, car ce sont eux qui gèrent les obligations et les échéances. Le service des achats gère le calendrier des renouvellements et dispose d’une marge de manœuvre pour renégocier les conditions. Le responsable de l’ingénierie et les éventuels partenaires d’agence soutiennent les estimations en précisant le degré de fiabilité de chacune d’entre elles. Le PDG ou le conseil d’administration intervient en dernier et a besoin d’un minimum d’informations : le montant minimal requis, le budget proposé et les options spécifiques entre les deux, chacune avec le résultat qu’elle protège ou rend possible.

Dans un cas fictif, le budget de la plateforme d’un détaillant régional se répartit entre des dépenses opérationnelles, des dépenses obligatoires liées à une version du cadre technique arrivant en fin de support et à un contrat de paiement renouvelable, ainsi qu’un poste discrétionnaire : la refonte du processus de paiement. Le service financier valide le scénario de référence et les fourchettes budgétaires. Le directeur du commerce électronique établit un lien entre la refonte et l’objectif de conversion. Le service des achats souligne alors que le délai de préavis du contrat de paiement expire avant le début de l’exercice budgétaire, ce qui nécessite d’entamer la renégociation suffisamment tôt. Le conseil d’administration peut alors prendre connaissance du montant minimum requis, du budget proposé et du choix spécifique à faire entre les deux : la refonte, avec son responsable et son objectif associés.

Présentez à votre partenaire financier le scénario de base et le registre des hypothèses avant la réunion officielle, afin que la réunion elle-même soit consacrée aux choix. Procédez à rebours à partir de la date de soumission du budget par le service financier, et prévoyez la première lecture par le service financier suffisamment tôt pour permettre des révisions.

Maintenir le budget à jour après validation

L'approbation ne marque pas la fin du processus de planification. Déterminez à l'avance quelles modifications de vos hypothèses doivent déclencher une nouvelle prévision si elles sortent de leur fourchette, et examinez le registre selon la fréquence déjà utilisée par le service financier. Suivez les résultats réels par rapport au scénario de référence, catégorie par catégorie, tout au long de l'année, afin que le scénario de référence de l'année suivante ne nécessite qu'une simple mise à jour du tableau plutôt qu'une reconstruction complète.

Foire aux questions

Que doit inclure le budget d’une plateforme web ?

Le budget d’une plateforme web doit couvrir l’hébergement et l’infrastructure, les licences, les services tiers, le développement, la maintenance et l’assistance, la sécurité et la conformité, la gestion de contenu, les outils d’IA, ainsi qu’une réserve pour imprévus. Chaque ligne doit indiquer le montant réel pour 2026, le montant prévu pour 2027, ainsi que la nature de la dépense (opérationnelle, obligatoire ou discrétionnaire), avec une règle d’allocation écrite pour les coûts partagés. Une catégorie manquante sous-estime le total et réapparaîtra plus tard sous la forme d’une demande imprévue.

Comment défendre un budget de plateforme web auprès d’un directeur financier ?

Présentez un scénario de référence lié au grand livre, distinguez les dépenses opérationnelles, obligatoires et discrétionnaires, et associez une source, un responsable et une fourchette à chaque hypothèse. Exprimez le retour sur investissement par ligne en termes déjà utilisés par le service financier : coûts évités, chiffre d’affaires préservé ou généré, capacités libérées et risques réduits. Préparez un tableau de scénarios de réduction afin que la discussion passe des pourcentages à des conséquences concrètes, et revoyez le scénario de référence avec le service financier avant la réunion officielle.

Quel pourcentage de son chiffre d'affaires une entreprise devrait-elle consacrer à la technologie ?

Il n'existe aucune référence vérifiée spécifique aux plateformes web. L'étude « 2026 Global Technology Leadership Study » de Deloitte, menée auprès de 662 responsables technologiques de haut niveau au sein d'organisations dont le chiffre d'affaires est d'au moins 1 milliard de dollars, fait état d'un investissement technologique représentant environ 6 % du chiffre d'affaires en 2026, qui devrait passer à environ 8 % au cours des deux prochaines années. Cette population étant constituée de grandes entreprises, une entreprise plus petite devrait considérer ce chiffre comme une référence contextuelle et utiliser son propre ratio d'une année sur l'autre comme référence.

Comment gérez-vous un budget stable ou réduit ?

Les dépenses obligatoires s’ajoutent au total ; un budget stable laisse donc moins de marge pour les dépenses discrétionnaires. Dressez la liste des postes discrétionnaires qui devraient être supprimés, indiquez le coût de chaque suppression à l’aide du tableau des scénarios de réduction, et laissez le service financier choisir parmi les options spécifiques. Si un poste obligatoire ne peut être financé, notez la date à laquelle il devient vulnérable et qui a accepté le risque.

Quels coûts liés aux plateformes web ne sont pas facultatifs en 2027 ?

Les coûts liés à une date ou à une obligation : les versions logicielles dont le support prend fin, comme Drupal 10 le 9 décembre 2026 ou PHP 8.2 le 31 décembre 2026, les renouvellements de contrat assortis de délais de préavis, et les obligations réglementaires lorsque le produit est concerné. Vérifiez vos propres versions et contrats par rapport aux dates mentionnées dans cet article, et classez tout le reste dans la catégorie des coûts facultatifs.

Des postes budgétaires à la décision

Cette approche fournit au service financier une base de référence traçable, rend visibles les coûts obligatoires et indique précisément ce qui peut être ajouté ou supprimé du budget proposé. Le choix de la plateforme est abordé dans notre guide d’audit des plateformes. Vous trouverez des conseils pour rédiger un bon brief concernant le projet que vous décidez de financer dans comment préparer votre projet web pour une agence. Si vous souhaitez obtenir un avis indépendant sur vos chiffres avant la réunion, notre service de conseil et d’accompagnement est conçu pour cela. Pour en discuter, contactez-nous.

Keroberos est un cabinet de conseil en technologies web qui accompagne les entreprises dans le choix de leur plateforme, livre des projets WordPress et Drupal, et fournit des prestations en régie pour les équipes de développement. Pour échanger sur le budget de votre plateforme web, contactez-nous.