Trois demandes, formulées presque à l’identique sur des projets différents, ont fini par disparaître de nos devis de développement de blocs sur mesure, non pas parce qu’elles étaient déraisonnables sur le principe, mais parce que leur coût réel dépassait systématiquement, et largement, ce qui avait été chiffré au départ.
« Un champ libre pour tout ce qu’on pourrait vouloir ajouter plus tard »
La demande semble anodine : un attribut de type texte libre, ou un champ de code HTML brut, permettant d’ajouter n’importe quel contenu supplémentaire sans repasser par un développement. En pratique, ce type de champ finit presque toujours par accueillir un contenu qui casse la mise en page, échappe à la validation du bloc, ou introduit une faille de sécurité si le champ n’est pas correctement assaini côté rendu. Chaque incident lié à ce champ « fourre-tout » revient ensuite en support, sans que le devis initial n’ait prévu ce temps de correction récurrent.
Un design non figé au moment du chiffrage
Développer un bloc avant que sa maquette ne soit définitivement validée revient à chiffrer une inconnue. Un changement de disposition demandé après le début du développement (passer d’une grille à trois colonnes à un carrousel, par exemple) ne se résume presque jamais à un ajustement mineur : la structure des attributs, la logique de InnerBlocks, parfois le rendu PHP entier doivent être repensés. Nous demandons désormais une validation de maquette explicite avant tout début de développement, avec un chiffrage séparé pour toute évolution structurelle ultérieure.
Une compatibilité illimitée promise avec des extensions tierces
« Le bloc doit fonctionner avec toutes les extensions de cache et de traduction du marché » : cette clause, autrefois acceptée sans discussion, s’est révélée impossible à honorer sérieusement. Une extension de cache agressive peut figer un rendu dynamique sans prévenir ; une extension de traduction peut dupliquer les attributs sérialisés d’une façon imprévisible. Tester exhaustivement contre l’ensemble des extensions existantes du marché représenterait un temps de qualification disproportionné par rapport au reste du développement. Le devis précise désormais une liste fermée d’extensions testées, avec une clause explicite excluant toute garantie sur les combinaisons non listées.
Ce que nous incluons à la place
- Une phase de cadrage courte mais obligatoire, avec maquette validée avant tout devis ferme.
- Une liste fermée d’attributs, documentée, sans champ « libre » non typé.
- Un périmètre de compatibilité explicite (thème et extensions réellement testés), plutôt qu’une promesse d’universalité.
- Un temps de test de non-régression chiffré séparément dès qu’un bloc dépasse une certaine complexité.
Pourquoi ces clauses profitent aussi au client
Un devis plus strict sur ces trois points ne vise pas à limiter la qualité livrée, mais à rendre visible, dès la négociation, ce qui coûterait sinon en support imprévu après livraison. Un client informé qu’un champ HTML libre entraînera des coûts de maintenance récurrents peut choisir en connaissance de cause d’accepter cette clause moyennant un forfait de support dédié, plutôt que de découvrir ce coût au fil des tickets ouverts après la mise en production.
Un devis qui refuse certaines demandes n’est pas un devis moins ambitieux : c’est un devis qui a déjà anticipé les tickets de support que la version précédente aurait générés sans le dire.
Un exemple concret de reformulation
Sur un projet récent de bloc « Fiche intervenant » pour un organisme de formation, la demande initiale prévoyait un champ de texte enrichi totalement libre pour la biographie. La reformulation retenue impose désormais une structure fixe (texte court, liste de qualifications, lien vers un profil détaillé), ce qui a réduit d’environ un tiers le temps de développement initial tout en supprimant la quasi-totalité des demandes de correction de mise en page reçues sur des blocs similaires livrés auparavant avec un champ libre.
En résumé
Les clauses retirées de nos forfaits de blocs sur mesure ne visent pas à réduire la liberté du client, mais à rendre explicite, dès le devis, un coût de maintenance qui existait déjà de façon invisible dans les versions précédentes. Un périmètre plus strict, mieux documenté, se traduit concrètement par moins de tickets de support imprévus après la mise en production.
