Gestion & Stratégie. Développement web sur mesure : le choix critique d'un CTO

Développement web sur mesure: le choix critique d’un CTO

Et, juste après, arrive la question qui fâche: « Donc on part sur du sur-mesure? »

C’est précisément là que le directeur technique doit sortir du réflexe identitaire. Un développement web sur mesure n’est ni la preuve qu’une entreprise est ambitieuse, ni l’assurance d’un produit mieux conçu. C’est un engagement: celui de financer des choix, de les documenter, de les maintenir et d’assumer les arbitrages quand le marché, les équipes ou les priorités changent. Sur les projets web, le sur-mesure ne rate pas parce qu’il est trop complexe. Il rate parce que sa complexité a été acceptée sans être réellement pilotée.

Environ 70 % des sites reposent sur un CMS. Ce n’est pas un aveu de faiblesse: c’est souvent une réponse rationnelle à un besoin standardisé. Les 30 % de projets conçus sur mesure répondent à une autre logique: processus métier singulier, expérience client différenciante, contraintes d’intégration fortes, volume de données inhabituel ou stratégie produit qui ne doit pas dépendre des limites d’un outil existant. La nuance est décisive.

Le mauvais débat n’est pas « CMS ou sur-mesure »

Lorsqu’une entreprise hésite entre développement sur mesure ou CMS, elle compare trop souvent des objets techniques. Or la vraie question est beaucoup plus concrète: quelle part de votre activité serait pénalisée si vous deviez contourner l’outil au lieu de faire évoluer votre produit?

J’ai vu une plateforme B2B partir sur un CMS parce que le délai de lancement était tendu. Décision saine, à ce stade. Le problème n’était pas le CMS; le problème était d’avoir traité comme une simple « évolution » ce qui allait devenir le cœur de leur modèle: des règles de tarification complexes, des droits d’accès mouvants, une logique de mise en relation entre plusieurs catégories d’utilisateurs et un suivi commercial très spécifique.

Après quelques mois, l’équipe ne faisait plus évoluer le produit. Elle négociait avec ses propres contournements.

« On ajoute juste un champ, ce n’est pas grand-chose », m’expliquait le responsable métier.

Le lead de développement avait une réponse beaucoup plus juste: « Le champ, non. Mais ce qu’il déclenche dans les droits, les exports, les relances et les statistiques, oui. »

Ce dialogue résume une réalité que les CTO doivent savoir rendre visible au comité de direction: le coût d’un choix ne se mesure pas à l’écran livré vendredi prochain. Il se mesure à la capacité de l’entreprise à prendre une décision dans six mois sans déclencher trois semaines de réparation.

Un projet web sur mesure devient cohérent lorsque le produit porte une valeur qui ne peut pas être achetée sur étagère ou configurée sans déformation. À l’inverse, vouloir fabriquer soi-même ce que le marché a déjà commoditisé est rarement une stratégie: c’est souvent une manière coûteuse de satisfaire une préférence interne.

Le développement PHP sur mesure, par exemple, peut être un excellent choix quand il s’inscrit dans une organisation qui sait ce qu’elle veut préserver: une propriété claire du code, une équipe capable de le faire vivre et une feuille de route où les priorités ne sont pas réécrites toutes les deux semaines par la dernière urgence commerciale.

Le sur-mesure n’est rentable que lorsqu’il protège une valeur que l’entreprise ne peut pas se permettre de banaliser.

Le CTO doit transformer l’intuition en décision gouvernable

Choisir le développement sur mesure ne consiste pas à dire: « Nous aurons plus de liberté. » Cette liberté existe, mais elle a une contrepartie immédiate: chaque zone floue devient une décision à financer. Les rôles utilisateurs, les exceptions commerciales, la reprise de données, les dépendances avec les outils internes, les règles de validation: sur un produit propriétaire, rien n’est gratuitement absorbé par une plateforme.

C’est pourquoi un bon CTO ne présente pas seulement une recommandation. Il pose une grille de décision devant les décideurs, de manière intelligible, sans les noyer sous des termes de spécialistes.

Voici les cinq questions que je conseille de mettre sur la table avant de choisir le développement sur mesure:

1. Quelle fonction crée réellement notre avantage concurrentiel?

Si la réponse est « notre contenu éditorial », « notre catalogue » ou « notre présence en ligne », un CMS bien gouverné peut suffire. Si elle concerne une mécanique métier fine — mise en relation, calcul, orchestration, personnalisation, conformité ou pilotage — le sur-mesure mérite d’être étudié sérieusement.

2. Quelles évolutions prévisibles allons-nous demander dans les dix-huit prochains mois?

Pas les rêves à cinq ans. Les évolutions probables: nouvelles offres, nouveaux pays, nouveaux rôles internes, intégrations, exigences de reporting. Une vision de produit approximative produit presque toujours un périmètre mal négocié.

3. Quels contournements sommes-nous prêts à accepter?

C’est une question de posture, pas de perfectionnisme. Une entreprise n’a pas besoin de tout posséder. Mais elle doit savoir quels renoncements restent acceptables, et lesquels fragilisent son modèle.

4. Qui décidera lorsque le besoin métier et la qualité du produit entreront en tension?

Sans product ownership solide, le sur-mesure devient une succession de demandes légitimes prises isolément, mais destructrices ensemble. Le CTO, le responsable produit et le métier doivent partager une même définition de la priorité.

5. Avons-nous les moyens humains de maintenir ce que nous construisons?

Ici, je parle autant de recrutement que de budget. Un produit stratégique confié à une équipe intermittente, sans transmission ni temps de consolidation, porte sa fragilité dès le premier jour.

Cette dernière question est souvent évitée, car elle oblige à regarder le marché de l’emploi en face. Recruter un développeur ne signifie pas uniquement pourvoir une capacité de production. C’est recruter une personne qui devra comprendre des décisions passées, challenger les prochaines et parfois dire non à une demande pourtant très populaire en réunion.

Pour un candidat, c’est aussi un signal à lire en entretien. Si une entreprise présente son projet sur mesure comme « une page blanche » mais ne sait pas expliquer qui arbitre, comment elle priorise et quelle place elle laisse à la maintenance, prudence. La page blanche est parfois un produit sans propriétaire.

La dette technique: le coût que l’on choisit de voir ou d’ignorer

La dette technique n’est pas un sujet de confort pour développeurs soucieux de propreté. C’est une variable de performance et, au fond, une variable de crédibilité managériale.

Le Technical Debt Ratio, ou TDR, donne un repère utile. Il rapporte le coût estimé de correction au coût initial de développement. Dans l’approche SQALE, un ratio inférieur ou égal à 5 % correspond à la meilleure note de maintenabilité, « A ». À partir de 50 %, la situation est considérée comme critique.

Naturellement, aucun indicateur ne résume la santé d’un produit. Une équipe peut afficher un ratio correct tout en souffrant d’une documentation absente ou de dépendances mal maîtrisées. Mais le TDR a un mérite: il permet de sortir de la conversation vague.

Au lieu de dire: « Le socle est un peu vieillissant », le CTO peut dire: « Chaque sprint, nous dépensons une part croissante de notre énergie à réparer les conséquences de décisions antérieures. Voilà ce que cela retire à la feuille de route. »

Les écarts sont loin d’être théoriques. Les équipes confrontées à un TDR supérieur à 25 % livrent 62 % de points de travail en moins par sprint que celles dont le ratio reste sous les 10 %. Derrière ce chiffre, il y a des choses très concrètes: une amélioration client reportée, une campagne impossible à lancer à temps, une intégration commerciale qui attend, des développeurs qui passent leur semaine à sécuriser l’existant plutôt qu’à construire.

« On a l’impression que l’équipe est lente », disait un dirigeant lors d’un diagnostic.

Non. L’équipe était occupée à payer les intérêts d’une dette que personne n’avait inscrite au budget.

Le piège est connu: tant que le produit génère du chiffre, les réparations semblent secondaires. Puis vient une demande importante — ouverture à un nouveau segment, changement réglementaire, rapprochement avec un partenaire — et l’organisation découvre que chaque évolution simple déclenche une chaîne d’incidents.

Le rôle du CTO consiste à ne pas dramatiser artificiellement, mais à rendre le coût visible avant la crise. Cela suppose de distinguer trois situations:

• La dette assumée, prise pour accélérer un lancement avec une date et un plan de remboursement clairs. Elle peut être rationnelle.
• La dette subie, née de décisions précipitées, de départs non remplacés ou d’un backlog mal tenu. Elle demande un diagnostic honnête.
• La dette dissimulée, celle que tout le monde connaît mais que personne ne formule devant les décideurs. C’est la plus dangereuse, parce qu’elle fausse les engagements commerciaux et les prévisions de charge.

Une dette technique non nommée finit toujours par devenir une promesse produit non tenue.

L’agilité ne sauve pas un projet mal cadré, mais elle évite de l’aveugler

Le mot « agile » a été assez maltraité pour mériter de la prudence. Certaines entreprises l’emploient pour désigner des réunions quotidiennes; d’autres y voient le droit de modifier la demande sans arbitrage. Ni l’un ni l’autre ne protège un projet.

L’intérêt d’une méthode agile, lorsqu’elle est réellement pratiquée, est de créer des boucles de décision courtes entre la valeur attendue, le travail engagé et les retours observés. Les projets pilotés avec des méthodes agiles affichent un taux de réussite supérieur de 28 % à ceux conduits selon des approches traditionnelles. Cela ne signifie pas qu’ils ne dépassent jamais les budgets, ni qu’ils évitent toute dette. Cela signifie qu’ils détectent plus tôt l’écart entre ce que l’on imaginait et ce que le produit exige réellement.

Les données historiques du Standish Group sont brutales: près de 83,9 % des projets informatiques rencontrent des difficultés partielles ou échouent complètement, avec des retards, des dépassements ou des abandons. Le CTO qui entend ce chiffre comme une fatalité se trompe. Il doit y entendre une invitation à piloter plus franchement les zones d’incertitude.

Dans un développement web sur mesure, l’agilité utile repose sur quelques disciplines simples, mais rarement confortables:

• un backlog qui exprime des objectifs et des conséquences métier, pas une liste infinie de souhaits;
• des démonstrations régulières où les décideurs regardent le produit réel, et non seulement des présentations;
• une capacité collective à retirer des sujets du périmètre quand la valeur n’est plus au rendez-vous;
• des temps explicitement réservés à la robustesse et à la maintenance;
• une mesure des délais, de la qualité et des incidents qui ne sert pas à surveiller les personnes, mais à ajuster le système.

J’insiste sur ce dernier point auprès des managers qui recrutent. Une équipe ne peut pas porter une stratégie produit si chaque indicateur devient un instrument de mise sous pression. Les bons profils, notamment ceux qui ont déjà vécu une reprise de projet difficile, savent faire la différence. Ils chercheront une direction technique qui assume les arbitrages, pas une organisation qui appelle « autonomie » le fait de laisser les développeurs seuls avec des priorités contradictoires.

La qualité doit être une règle du jeu, pas un discours de fin de sprint

Sur un projet sur mesure, la qualité n’est pas une décoration ajoutée lorsque les fonctionnalités sont terminées. Elle se négocie au même moment que la vitesse, le budget et le périmètre. Si elle arrive après, c’est qu’elle est déjà en retard.

Des outils de suivi peuvent aider à objectiver cette conversation. La barrière de qualité standard de SonarQube, par exemple, fixe des exigences nettes sur le nouveau code: un ratio de dette technique inférieur ou égal à 5 %, une couverture de tests d’au moins 80 %, et aucun nouveau bug ou défaut de sécurité identifié. Il ne s’agit pas de transformer la gestion de projet en concours de tableaux de bord. Il s’agit d’empêcher qu’une livraison urgente fasse entrer dans le produit un problème que l’équipe devra payer longtemps.

Dans les recrutements de responsables techniques, j’écoute toujours la manière dont un candidat raconte un désaccord de ce type. La réponse la plus rassurante n’est pas: « J’ai toujours tenu bon sur la qualité », formule un peu trop propre pour être vraie. C’est plutôt:

« Nous avions un lancement commercial important. Nous avons livré l’essentiel, décalé deux demandes secondaires et inscrit le travail de consolidation dans le sprint suivant, avec l’accord explicite du métier. »

Voilà une posture mature. Elle ne sanctuarise pas la technique contre le business; elle refuse simplement que le business obtienne une fausse victoire en consommant la capacité future de l’équipe.

Le chef de projet technique a ici un rôle déterminant. Il doit traduire les signaux de qualité en impacts compréhensibles: risque sur la date, fragilité d’un parcours client, surcharge d’exploitation, baisse de capacité pour les prochaines priorités. S’il se contente d’envoyer un rapport d’audit technique, il laisse les autres faire l’effort d’interprétation. Et, dans une organisation pressée, cet effort ne sera pas fait.

Prévoir le budget de consolidation, c’est protéger l’innovation

Les entreprises les plus solides consacrent en moyenne 15 % de leur budget informatique à la résolution et à la gestion de la dette technique. Ce chiffre ne doit pas devenir une règle automatique: un produit récent et bien cadré n’a pas les mêmes besoins qu’un système qui porte dix ans d’arbitrages. Mais il donne un ordre de grandeur utile pour sortir de l’illusion selon laquelle la maintenance serait une dépense exceptionnelle.

Elle ne l’est pas. Elle est le prix de l’autonomie.

J’entends souvent: « Nous préférons investir dans les nouvelles fonctionnalités. » Je comprends la pression. Les nouvelles fonctionnalités sont visibles, commercialisables, faciles à raconter. Pourtant, une organisation qui ne finance que le neuf finit par réduire sa propre marge de manœuvre. Chaque nouveauté devient plus lente, plus risquée, plus coûteuse à déployer.

Le budget de consolidation doit couvrir bien davantage qu’une vague ligne « maintenance »:

• la correction des fragilités repérées par les équipes et les audits;
• le temps de transmission entre développeurs, chefs de projet et responsables produit;
• la mise à jour des dépendances et des pratiques de sécurité;
• la simplification des parcours internes devenus inutilement lourds;
• la documentation des décisions qui devront être comprises par les futurs recrutés;
• la réduction volontaire du backlog, car tout ce qui reste ouvert n’a pas vocation à devenir un jour une priorité.

C’est aussi une question de marque employeur, même si l’expression est souvent utilisée à tort et à travers. Les développeurs expérimentés ne demandent pas un environnement parfait. Ils savent que cela n’existe pas. En revanche, ils veulent savoir si l’entreprise traite ses contraintes avec lucidité. Un CTO qui peut expliquer où se situe la dette, ce qui est financé et comment l’équipe participe aux arbitrages inspire beaucoup plus confiance qu’un discours sur « l’innovation » sans budget ni méthode.

Le vrai choix: construire une capacité de décision durable

Choisir un développement sur mesure, c’est choisir de rendre son organisation responsable de ce qu’elle met en production. Cette responsabilité ne se délègue ni à une agence, ni à un outil, ni à une équipe recrutée dans l’urgence. Elle se partage, avec une direction technique capable de dire ce qui crée de la valeur, ce qui doit attendre et ce qui risque de coûter trop cher demain.

Si vous êtes CTO, votre plan d’action n’a pas besoin d’être spectaculaire. Commencez par remettre à plat les fonctions réellement stratégiques du produit. Identifiez les contournements qui consomment déjà l’énergie des équipes. Donnez un nom et une mesure à la dette technique. Réservez une part visible du budget à la consolidation. Enfin, créez des rendez-vous où le métier voit les conséquences de ses choix avant que celles-ci ne deviennent des incidents.

Et si vous rejoignez une entreprise qui lance un projet web sur mesure, posez ces questions en entretien. Qui porte la vision produit? Comment les priorités sont-elles arbitrées? Quelle place est donnée à la maintenance? Que se passe-t-il lorsqu’une livraison rapide dégrade la qualité?

Les réponses vous diront davantage sur la maturité de l’entreprise que son discours sur la modernité. Un bon projet sur mesure ne se reconnaît pas à la quantité de code produite. Il se reconnaît à sa capacité à continuer d’évoluer sans épuiser les personnes qui le font vivre.