Récemment, j’ai eu l’occasion de discuter avec un responsable technique d’un gros site e-commerce d’une grande marque française. Il m’expliquait qu’après avoir remarqué une erreur de texte sur une page dynamique du site, une demande de modification avait été faite auprès de leur équipe technique. L’équipe en question a alors réalisé un chiffrage de temps et de budget pour cette modification. Et le résultat m’a laissé sans voix : pour changer une ligne de texte, la modification a été estimée à 6 mois de travail, un budget de 15 000€, en faisant intervenir une quinzaine de personnes (un intégrateur, un développeur, un responsable technique, un responsable maintenance, un chef de projet, un responsable marque, etc…).
Ce n’est pas la première fois que je rencontre ce genre d’estimations, en particulier dans des grands groupes. Quand je travaille avec de nouveaux clients, ça m’amène à me poser régulièrement cette question : Combien de temps vous faut-il pour changer un « s » ? Combien de temps vous faut-il pour corriger une simple faute d’orthographe ? Combien de temps vous faut-il pour faire une simple modification de texte ?
En tant qu’intégrateur, j’aurais envie de répondre 5 minutes. Mais j’aurais certainement tort. Rien ne prends jamais 5 minutes. En réalité, je pense qu’il faut compter au minimum 15 minutes. C’est le temps qu’il me faut pour lire la demande, ouvrir le projet dans Coda, trouver le fichier à modifier, faire la modification, vérifier que ça marche bien en local, mettre en ligne, vérifier que ça marche bien en ligne, et répondre au client que la demande a été traitée. Si vous êtes freelance, et que vous travaillez seul sur la totalité d’un projet, vous serez surement assez proche de cette estimation.
Dans une petite ou moyenne agence, il faudra sans doute compter un peu plus d’intervenants. Un chef de projet va recevoir la demande du client et se chargera de la transmettre aux personnes concernées en interne. Un intégrateur pourra alors s’occuper de faire la modification. Une fois le tout vérifié par le chef de projet, un responsable technique pourra alors s’occuper de la mise en ligne. Pour une modification un peu plus complexe, il faudra peut être repasser par un graphiste et faire valider le tout avant intégration par le client. Au total, on atteint facilement une à deux heures de travail.
Dans une très grosse entreprise, c’est souvent bien pire. Il y a 2 ans, j’avais tweeté cet article intitulé « Combien faut-il d’employés chez Microsoft pour changer une ampoule ?« . La liste est particulièrement longue et impressionnante :
- Un développeur pour passer 5 minutes à implémenter ChangeLightBulbWindowHandleEx
- Un responsable programme pour écrire la spécification.
- Un expert localisation pour repérer d’éventuels problèmes de localisation dans la spécification.
- Un expert en utilisabilité pour repérer d’éventuels problèmes d’accessibilité et d’utilisabilité dans la spécification.
- Au moins un développeur, un testeur et un chef de projet pour réfléchir à des vulnérabilités de sécurité.
- Un chef de projet pour ajouter le modèle de sécurité à la spécification.
- Un testeur pour écrire le plan de test.
- Un responsable de tests pour mettre à jour le planning de tests.
- Un testeur pour écrire les cas de tests et les ajouter aux tests nocturnes automatiques.
- Trois ou quatre testeurs pour participer à de la chasse aux bugs.
- Un rédacteur technique pour écrire la documentation.
- Un relecteur technique pour vérifier la documentation.
- Un rédacteur pour relire et corriger la documentation.
- Un responsable de la documentation pour intégrer la nouvelle documentation dans le contenu existant, en mettant à jour les sommaires, etc.
- Vingt-cinq traducteurs pour traduire la documentation et les messages d’erreur dans toutes les langues supportées par Windows. Les managers des traducteurs vivent en Irelande (pour les langues européennes) et au Japon (pour les langues asiatiques), qui sont toutes deux fortement en décalage horaire avec Redmond, donc échanger avec eux peut devenir un problème logistique assez complexe.
- Une équipe de managers sénior pour coordonner tous ces gens, signer les chèques, et justifier leur coût à leur Vice Président.
On comprend vite comment on peut arriver à 6 mois pour une demande pourtant aussi simple. Si cela peut prêter à sourire chez Microsoft, je pense que ce mode de fonctionnement est particulièrement inadapté pour le web. Sur le web, votre capacité de réactivité doit l’emporter à votre administrativité. Débrouillez vous pour diminuer le nombre d’intervenants. Donnez plus de responsabilités à vos collaborateurs. Mais s’il vous faut plus de deux heures pour changer un « s », il y a peut être quelque chose qui cloche dans votre organisation.
Aurélien, le
Je suis encore une fois jaloux de cet article…
J’aurai voulu l’écrire…
Prélude, le
Je fais rarement des sites pour des clients (je bosse pour moi essentiellement). Mais cela m’arrive. Dans ce cas, je demande 1 heure au minimum pour une intervention. Et je propose, s’il n’y a pas d’urgence, de regrouper les demandes afin de réduire les coût pour mon client et de rendre le travail plus passionnant pour moi.
Donc, pour un « s », je prend 1 heure dans le meilleur des cas.
Mandragora, le
Si lors de l’intégration la personne qui l’avais faite avait été intelligente, ce serait éditable par le client et non en dur dans le code (ou en HTML) …
Du coup, aucun temps pour l’intégrateur ou l’agence.
Après, il est clair que tous les textes ne sont pas forcément éditable mais lorsque l’on utilise un CMS il faut prévoir les outils adéquats et pour le coup gagner du temps ;)
Yo, le
« Débrouillez vous pour diminuer le nombre d’intervenants. Donnez plus de responsabilités à vos collaborateurs. Mais s’il vous faut plus de deux heures pour changer un « s », il y a peut être quelque chose qui cloche dans votre organisation. »
D’un autre côté, cela ouvre la voie au chef de projet fonctionnel de te dire que ça prends que 2 minutes à te connecter au serveur de prod et à faire la modification en direct, quitte à faire planter la production à cause d’une balise supprimée involontairement… (et c’est du vécu !)
thomasmds, le
Peut être que dans une grosse structure, il serait nécessaire de créer une cellule dédiée (si ce n’est pas déjà le cas), aux modifications comme celles là. Notamment sur le web.
Je n’est pas d’exemple précis en tête, mais il me semble avoir déjà vu des erreurs sur des sites web de grandes entreprises comme Apple, etc. Et ces erreurs ont étaient corrigés très rapidement (24h maximum). Et non pas en 6 mois.
Enfin c’est sur que 6 mois pour une simple correction d’erreur sur un site web, c’est beaucoup trop. Sur un logiciel, en principe, si une erreur se glisse dans une version finale, on accélère beaucoup le processus de mise à jour (il y en a toujours un en cours forcément), et l’erreur est corrigée par la mise à jour.
Agnès, le
J’ai travaillé chez un client qui avait bien rodé ses processus de bugfix sur la prod. On fonctionnait avec une mise en production par semaine (le jeudi), avec deux jours de développement ou bugfix (par les dev), un demi-jour de tests unitaires croisés (par les dev), un jour de recette fonctionnelle (par les marketeux) et un quart d’heure de mise en ligne (par le lead dev au téléphone avec le mec de la prod).
Du coup certains bugs mineurs pouvaient mettre jusqu’à une ou deux semaines pour être corrigés, mais on mutualisait le temps : on n’avait pas à interrompre autre chose pour la recette ou les corrections parce qu’on savait à l’avance quels jours de la semaine étaient dédiés à quoi.
Du coup ça fait un peu usine à gaz comme ça, mais c’est paradoxalement le système le plus efficace que j’ai vu depuis que j’ai commencé à travailler. Pas d’énormes spécifications, pas d’interminables réunions de validation dans les hautes sphères de décision, et un site qui continue à vivre au fur et à mesure des semaines.
(NB. On avait une exception dans le processus pour les bugs majeurs en prod : dans ce cas on restreignait la recette à l’équipe de dev et le correctif pouvait être en ligne dans l’heure suivant la découverte du problème. Mais on n’avait pas beaucoup de bugs majeurs en prod, vu qu’on avait bien éduqué les gens qui faisaient la recette. :) )
Arnaud, le
Je pense qu’il faut travailler dans une grosse boite pour comprendre pourquoi ce n’est pas si simple. J’ai bossé plusieurs années au sein d’un système d’information dans le monde des télécoms. En 6 ans, les plus grosses pannes étaient souvent causées par des petites modifications insignifiante.
Par exemple, on a déjà vu un serveur de production tomber en quelques heures parce qu’un jeune développeur avait commenté une ligne de code en urgence pour une demande du service communication. Sauf que cette ligne a généré énormément de logs dans une boucle et a généré plusieurs Go sur le serveur en quelques minutes.
Je me rappel également d’une modification de texte sur un extranet ou le développeur c’est dit qu’il allait faire ça sens communiquer. Résultat, il a poussé la modification sur l’extranet Marque Blanche et tous les revendeurs se sont retrouvé avec un beau message indiquant le nom du partenaire, …
Actuellement, j’ai monté ma propre agence web et même si on peut faire une modification beaucoup plus rapidement, c’est toujours difficile d’expliquer a un client que pour corriger une faute d’orthographe, il faut tester, mettre à jour le SVN ou GIT, lancer quelques scripts (vider le cache, …) et que ça ne prends jamais 5 min.
frinux, le
Ça va en général de pair avec l’annonce du prix d’un site. Quand certains y voient quelques milliers d’euros, ils n’arrivent pas à comprendre qu’on chiffre leur projet à 50k…
Michael, le
En utilisant un CMS, 0 minutes pour changer le S, c’est le client qui s’en occupe. Maintenant, si on parle de bug dans les CSS, ça prend un tout petit peu plus de temps, tout dépend où le site est hébergé (si le site est hébergé c’est chez lui, ça prend beaucoup plus de temps, mais souvent ils ont des compétences en interne pour faire des modifications dans ce cas là).
Mais effectivement, on comptant large, une demi heure minimum avec la lecture de la demande, le traitement, la réponse au client, etc.
Fabien, le
Le principal c’est toujours pareil : expliquer au client pourquoi il faut 2 heures pour une modif et cet article donne de bonne pistes. C’est comme la ligne « maintenance » sur le devis, je connais beaucoup de petites boîtes qui « n’ose pas » mettre le prix réel derrière. Pourtant on le sais tous (on devrait le savoir !), c’est ces petits détails qui plombent les projets, autant sur les prix que sur les nerfs !
Da Scritch, le
Si le CMS/service e-commerce a prévu le coup (ce que je fais depuis 5 ans), t’y penses même pas, même s’il s’agit de changer un paquet d’adresses.
eheheh
Le Juge, le
Arf… c’est tellement vrai des fois – notamment pour les sites de grands groupes qui ont été migré sur des CMS inhouse il y a une decenie et dont les plateformes sont de véritables usines a gaz
ZaFoX47, le
Aurélien, ce serait pas un autre pseudonyme de l’auteur de cette article non ?
Faut pas exagérer, et si le client n’est pas capable de voir qu’il y a un problème avec un tel chiffrage, pourquoi n’engage-t-il pas des personnes qualifiées en interne ? À trop vouloir faire appel à des SSII, on se retrouve dans des situations où l’abus peut devenir régulier !
Pierre Barthelemy (@Ivanoff), le
Bah, ce genre de chiffrage est une honte. Mais comme le dis le Juge, sur certaines plateforme inhouse c’est des usines a gaz…
Maintenant, dans certaines sociétés (dont la mienne), on a une équipe pour ce genre de chose et aucune modification n’a pris plus de quelques jours (sinon c’est de l’évolution donc un nouveau projet !)
Nico, le
Huhu, ce genre d’article me fait sourire, j’ai tellement vu ce genre de cas extrême dans certains groupes. C’est particulièrement rigolo quand on est « un petit » au milieu de ces grands : le temps qu’ils discutent sur comment ils vont organiser le truc… en fait, c’est déjà réalisé chez « les petits ». J’aurais une quantité d’exemples où je suis passé pour un mutant aux yeux de ces grands groupes ! :)
Ceci dit, pour être honnête, il faut distinguer les lenteurs :
– soit c’est organisationnel : la secrétaire va transférer au CP qui transfère au chef des devs, qui transmet au dev, etc… et c’est lent car ça doit transiter par beaucoup de personnes.
– soit c’est dû à la complexité du projet : modifier un champ impacte plein de modules. Là, c’est normal qu’il faille du temps.
Ceci dit, pour changer un « s » et ce genre de demandes triviales, effectivement, ça doit prendre très peu de temps, sinon y a un problème. C’est là qu’une certaine maitrise de son environnement permet de gagner du temps.
Thomas, le
Dans une agence web où je suis passé, on avait intégré les « rotations » pour ce genre de micro-bug.
Chaque jeudi matin, à tour de roule, un développeur habilité était dédié aux petits débugs accumulés au longs de la semaine.
Par développeur habilité, j’entends développeur ayant l’expérience nécessaire pour faire ça sans contrôle par un chef de projet, et pour avoir accès à la production.
Du coup c’était double gain pour les développeurs :
– les chefs de projets gardaient ça sous le coude pour le jeudi matin sans nous déranger à longueur de journée.
– pour les développeurs, on regroupait ces petites tâches, et ça ne nous concernait en moyenne qu’une fois par mois. Du coup facile d’organiser son temps.
Dans ce premier cas on garantissait une rectification sous 7jours max pour le client pour des bugs mineurs.
Dans les cas de bugs moyens, le développeur responsable du projet concerné était planifié le lendemain sur le debug.
Le temps de résolution était donc de 1 journée en moyenne selon le temps nécessaire à résoudre le bug.
Pour les bugs majeurs … là c’était plus simple : on arrête tout, et on se plonge dedans pour fixer au plus vite.
Du coup je trouve qu’on avait une échelle cohérence niveau urgence/délais, tout en optimisant les plannings de chacun.
François-Olivier, le
Comme je me retrouve dans cet article… Je suis Consultant / Chef de projets SEO en agence et travaille sur des e-commerce grand compte. Pour un de mes clients (+ de 300 millions d’euros de CA annuels), j’ai fait chiffrer par l’agence de développement la réalisation des optimisations onsite les plus basiques qui soient au niveau SEO (des title différents sur chaque page, un fil d’ariane, et quelques broutilles de ce genre). Estimation fournie : 50 jours à +/- 30%…
Très sincèrement, sur un site classique géré par une petite agence et sur un système non propriétaire (donc sur de l’open source), ça aurait pris 3 jours au total, recette inclue.
Dans ces 50 jours, 70% était du à de la lourdeur interne, procédure, process, « jefaisriensij’aipasundocprécissigné », … etc.
Mais après tout, ce n’est pas propre au web. J’ai travaillé en grande distribution dans un groupe géant de 250 000 salarié, pour avoir une imprimante dans mon service la procédure d’autorisation a pris deux semaines et a fait intervenir 5 personnes à travers deux pays…
César, le
Assez d’accord avec Arnaud.
Attention à la correction en production en 10 minutes parce que ça paraît juste un « petit » truc au départ et en fait on produit des bugs sous estimés ensuite. Il faut trouver un juste milieu.
chrishrmnn, le
Je crois que ton article a inspiré quelqu’un : http://www.commitstrip.com/fr/2012/08/17/faudrait-juste-changer-un-mot-ou-deux/ :)
Jal, le
La dimension de la société est importante : plus il y a d’acteurs et plus c’est compliqué.
En free-lance, on est généralement l’auteur du code (à moins de récupérer un projet pour le débugguer et/ou ajouter à un existant de nouvelles fonctions) et on travaille souvent seul.
Plus facile donc d’accéder aux sources et de chainer les différentes étapes jusqu’au déploiement du correctif.
Dès que l’on pense à une structure à deux intervenants, c’est déjà différent…
Rien qu’avec deux développeurs, il faut s’assurer que l’on prend bien la dernière version de fichier.
Pour la partie rédactionnelle, généralement je demande les textes au client et je ne fais pas de relecture et je le précise bien. Si le système mis en place ne dispose pas d’un CMS, je facture ou je mets en place un nombre d’heures (que je facture dans le projet) et qui premet ce type d’ajustement.