Chaque modification de page passe par un ticket, chaque ticket prend une semaine, et la facture mensuelle dépasse les 10 000 euros pour de « petites retouches ». Cette situation — décrite il y a quelques jours dans une discussion récente sur Reddit par une équipe de quinze personnes sans développeur interne — est beaucoup plus répandue qu’on ne le croit. Elle révèle moins un problème de prix qu’un problème d’organisation : quand un prestataire devient le seul chemin possible pour changer un texte, l’entreprise a cédé le contrôle de son propre outil de travail.
Le ticket qui coûte plus cher que le travail
Le symptôme est toujours le même. Une landing page à modifier, un bloc à déplacer, un bouton à corriger : la demande part en ticket, entre dans la file d’attente de l’agence, et revient une semaine plus tard. À raison de plusieurs tickets par mois, la facturation récurrente se justifie « par la disponibilité », pas par le volume de travail réellement fourni. L’entreprise finit par payer un droit d’accès à son propre site plutôt qu’une prestation.
Le vrai coût n’est d’ailleurs pas la facture : c’est la latence. Chaque semaine de délai sur un test, une offre ou une campagne, c’est de l’argent qui n’entre pas. Une équipe commerciale qui ne peut pas modifier sa page d’accueil sans passer par un tiers est structurellement ralentie face à des concurrents qui, eux, décident en interne.
Ce que la communauté en retient
Dans la discussion d’origine, les retours divergent — et c’est instructif. Plusieurs intervenants jugent le tarif « hors norme » et évoquent des coûts de maintenance réalistes six à dix fois inférieurs pour des sites comparables. D’autres estiment au contraire que le montant importe peu tant que le problème de fond n’est pas réglé : une partie des tickets envoyés à l’agence n’était pas du développement, mais du contenu — du texte, des images, de la mise en page. Le prestataire facturait des compétences techniques pour des tâches qui n’en demandaient pas.
Ce constat partagé est le plus utile : avant de parler argent, il faut regarder ce qui part en ticket. Souvent, la moitié de la « facture de développement » finance des modifications de contenu que l’entreprise pourrait assumer seule avec les bons outils. Le reste — vraies évolutions, intégrations, sécurité — mérite une vraie discussion de prix, mais sur un périmètre clarifié.
Reprendre la main : la méthode en quatre temps
La sortie de la dépendance se joue en quatre étapes, chacune réversible et peu coûteuse :
- Auditer la demande. Pendant deux semaines, consigner chaque demande envoyée au prestataire et la classer : contenu (texte, image, ordre des sections) ou code (intégration, donnée, sécurité). Le verdict est généralement sans appel : l’essentiel relève du contenu.
- Séparer la maintenance des projets. Remplacer le forfait global par un petit budget horaire ou à la demande pour les corrections, et chiffrer séparément les évolutions significatives. On paie alors le travail, pas l’accès.
- Reprendre possession de la technique. Récupérer la liste complète de l’hébergement, des domaines, des accès, des dépôts de code et du processus de mise en ligne. Tant que ces éléments sont dans les mains du prestataire, tout changement de fournisseur — ou toute reprise en interne — est impossible.
- Équiper l’équipe. Pour les modifications de contenu, mettre en place un outil simple (CMS léger, gabarits de pages approuvés) permettant à l’équipe de modifier elle-même les sections standard, sans toucher au code.
Cette démarche permet ensuite de comparer sereinement : mêmes besoins listés, demandes de devis à deux ou trois prestataires, avec des délais de réponse contractualisés. Le marché français regorge de développeurs indépendants ou de petites structures capables d’assurer une maintenance de qualité à une fraction des tarifs d’agence — à condition de pouvoir définir précisément ce qu’on leur demande.
Les pièges à éviter
Le premier réflexe — changer d’agence — est rarement la bonne réponse si l’organisation n’a pas changé : une autre agence appliquera la même file d’attente au même type de demandes. Le deuxième piège est l’inverse : tout faire soi-même. Sans compétence technique interne, confier la modification d’une base de données ou d’une intégration à quelqu’un qui découvre le sujet est un risque de sécurité et de régression. Le troisième, plus subtil : remplacer l’agence par une personne non remplaçable — un prestataire unique, sans documentation, sans accès partagés, qui reproduit à l’identique la dépendance initiale. La règle est simple : l’autonomie se construit par la documentation et l’appropriation des accès, pas par un simple changement d’interlocuteur.
Enfin, les outils d’IA générative — cités spontanément dans la discussion, parfois avec excès — peuvent traiter une partie des modifications simples, mais ils ne remplacent ni la propriété du code ni la validation d’un regard compétent. Les considérer comme un accélérateur, pas comme une délégation en blanc.
Ce qu’il faut retenir
Une facture de développement qui explose pour des modifications simples n’est pas une fatalité : c’est presque toujours le signe que l’entreprise a externalisé, avec le code, la capacité de décision sur ses contenus. Réorganiser la demande, documenter le système et reprendre la main sur les accès redonne la liberté de choisir — et de négocier. La discussion Reddit à l’origine de cet article le résume bien : ce n’est pas le prix qui est le problème, c’est le ticket.