« Ce n’est qu’un instant »
Toute personne qui travaille à la création ou à la maintenance d’un site web, d’une application ou d’un système connaît ce message.
« Pouvez‑vous juste changer ce bouton ? »
« C’est vraiment une petite correction. »
« Merci de simplement déplacer cet élément. »
« Est‑ce que ça peut être fait rapidement ? »
« Ça doit faire 5 minutes de travail, non ? »
Et parfois, en effet, c’est le cas.
Parfois, changer la couleur d’un bouton prend quelques minutes. Parfois corriger une faute d’orthographe demande un seul clic. Parfois le développeur ouvre le code, regarde, modifie une ligne et c’est réglé.
Le problème, c’est que toute modification qui paraît petite du point de vue de l’utilisateur n’est pas forcément petite du point de vue du système.
Et le vrai problème apparaît lorsque ces « petites modifications » sont plusieurs dizaines, voire des centaines par mois. C’est là que quelque chose d’intéressant commence à se produire.
L’entreprise peut avoir l’impression qu’elle ne commande rien de majeur. Et en même temps, l’équipe IT passe une part notable de son temps à réaliser justement ces petites tâches.
Et ici se pose la question : Combien coûte vraiment un bouton « Corrigez‑le vite » ?
Commençons par un exemple simple
Imaginons que l’équipe marketing envoie au software house le message suivant :
« Hé, nous devons juste changer le texte du bouton. Au lieu de « Découvrir l’offre » il devrait y avoir « Découvrez l’offre ». C’est une petite chose, merci de le faire vite. »
Ça paraît banal. Mais du côté technique, cela peut être tout à fait différent.
Le développeur doit :
1. Analyser la demande
Où se trouve ce bouton ?
Est‑il présent à un seul endroit ?
Apparaît‑il dans plusieurs versions de la page ?
Le texte est‑il écrit directement dans le code ?
Est‑il géré par un CMS ?
Le changement concerne‑t‑il la version desktop et mobile ?
Le bouton fait‑il partie d’un composant réutilisé ailleurs ?
2. Implémenter le changement
Changer le texte.
Refondre le composant.
Mettre à jour le contenu dans le CMS.
Ou modifier le code.
3. Vérifier le résultat
Le bouton s’affiche‑t‑il correctement ?
Le texte ne déborde‑t‑il pas de sa zone ?
Sur mobile tout fonctionne‑t‑il ?
Le changement n’a‑t‑il pas affecté d’autres endroits ?
4. Tester
Peut‑on cliquer dessus ?
Le lien mène‑t‑il à la bonne destination ?
Un bug n’est‑il pas apparu ?
5. Déployer le changement
Si le changement nécessite un déploiement, il faut le mettre en production.
Et il s’avère soudain que : « Changer uniquement le texte »
n’implique pas forcément : « Juste 5 minutes de travail ».
Combien peut coûter une petite modification ?
Prenons un scénario très conservateur.
Le développeur consacre :
- 15 minutes à l’analyse,
- 20 minutes à l’implémentation,
- 15 minutes aux tests,
- 10 minutes à la préparation et au déploiement.
Total : 60 minutes de travail.
Et ici arrive un point important. Si le taux horaire de l’équipe est par exemple de 200 zł nets, une modification apparemment mineure coûte environ : 200 zł nets.
Mais ce n’est pas tout. Dans le processus réel peuvent apparaître :
- le transfert de la tâche,
- la clarification du périmètre,
- des questions au client,
- attente d’une réponse,
- vérification du résultat par la personne ayant signalé,
- correction après feedback,
- redéploiement.
Une heure peut donc très facilement se transformer en deux. Et une petite modification en plusieurs heures de travail de toute l’équipe.
Le plus coûteux n’est pas l’exécution
Cela peut sembler paradoxal. Parfois l’exécution seule prend 10 minutes. Mais la préparation en prend 20 de plus. Puis il y a les tests, le déploiement, la communication et le changement de contexte.
Et c’est souvent ce dernier élément qui est le plus sous‑estimé.
Changement de contexte — le coût caché des petites tâches
Le développeur travaille sur une grande fonctionnalité. Il a le code ouvert. Il analyse un problème. Il est concentré.
Soudain, arrive un message : « Hé, c’est juste une petite chose. Peux‑tu corriger le bouton ? »
Le développeur interrompt son travail. Il ouvre la demande. Il vérifie la page. Il cherche l’endroit dans le code. Il implémente le changement. Il teste. Il déploie. Puis il revient à la tâche précédente…
Et il doit se rappeler : « Sur quoi j’étais déjà ? »
C’est précisément le changement de contexte, et il peut être très coûteux. Pas parce que chaque petite modification demande beaucoup de travail, mais parce que chaque interruption casse le flux de pensée.
Plus la tâche interrompue est complexe, plus le coût du retour est élevé. C’est pourquoi 10 micro‑tâches ne signifient pas toujours 10 × 10 minutes. En pratique, cela peut représenter bien plus.
Un bouton, ce n’est rien. Cent boutons, c’est déjà un processus.
Supposons que l’entreprise envoie à l’équipe technique :
- 20 petites modifications par mois,
- chacune prenant en moyenne 45 minutes.
Cela donne : 15 heures de travail par mois.
Au taux de 200 zł nets : 3000 zł nets par mois.
Par an : 36 000 zł nets.
Et on ne parle que de 20 petites tâches par mois. Sans nouvelles fonctionnalités. Sans développement produit. Sans nouveaux modules. Sans intégrations. Sans design.
Juste : « changez », « corrigez », « déplacez », « ajoutez », « supprimez ».
Imaginez maintenant une organisation où ces tâches sont 50 par mois. Ou 100.
L’échelle commence à paraître complètement différente…
Les micro‑tâches ont un autre coût — elles bloquent le développement
C’est un des éléments les plus importants de l’ensemble.
Si l’équipe de développeurs passe 20 % de son temps sur de petites corrections, elle ne peut pas consacrer ces 20 % au développement du produit. Cela semble évident. Mais dans la pratique, on ne le voit pas toujours.
L’entreprise demande : « Pourquoi la nouvelle fonctionnalité n’est‑elle pas encore prête ? »
Le développeur répond : « Parce que nous avions beaucoup de sujets courants. »
« Lesquels ? »
« Des corrections, de petites modifications, des mises à jour, des petites tâches. »
Chacune était petite. Mais ensemble elles ont créé un énorme bloc de travail. C’est un peu comme les notifications sur un téléphone. Une notification ne gêne pas. Dix un peu. Cent ? Soudain, on réalise qu’on a passé la journée à réagir.
Avec les micro‑tâches, c’est la même chose.
« Petite tâche » n’est pas toujours une petite tâche
Il faut aussi comprendre que toutes les modifications ne se valent pas. Changer le texte dans un CMS peut réellement prendre quelques minutes.
Mais changer le texte dans une application peut nécessiter :
- de retrouver le composant,
- de modifier le code,
- de mettre à jour les traductions,
- des tests,
- la recompilation de l’application,
- le déploiement.
Modifier un seul champ peut nécessiter des changements :
- front‑end,
- back‑end,
- base de données,
- API.
Changer un élément dans le système peut impacter d’autres éléments.
C’est pourquoi la question : « Combien prendra le changement de ce bouton ? »
sans connaissance de l’architecture du système n’a souvent pas de réponse sensée.
Il faut d’abord vérifier. Puis estimer.
Pourquoi le développeur dit parfois : « Je dois vérifier » ?
Ce n’est pas une façon d’éviter une réponse. C’est souvent le signe de professionnalisme.
Un bon développeur ne devrait pas promettre : « Oui, bien sûr, cinq minutes »
s’il ne sait pas ce qu’il y a en dessous.
Il devrait dire : « Je vais vérifier où cet élément est utilisé et je vous tiens au courant. »
Cela peut prendre 10 minutes. Mais ces 10 minutes peuvent économiser plusieurs heures de problèmes. Car la modification la plus coûteuse n’est pas forcément celle qui prend une heure.
La plus coûteuse est celle qui :
- casse une autre fonctionnalité,
- provoque une erreur en production,
- nécessite un rollback urgent,
- génère d’autres tickets,
- requiert l’intervention de plusieurs personnes.
C’est pourquoi l’analyse avant le changement fait partie du travail, et non une perte de temps.
Comment le client peut réduire le coût des micro‑tâches ?
Il ne s’agit pas d’arrêter de signaler de petites modifications. Les petites modifications sont une partie normale du développement d’un produit. Il s’agit de mieux les gérer.
1. Grouper les petites tâches
Au lieu d’envoyer :
« Changez le bouton. »
« Aussi, corrigez ce titre. »
« Et par la même occasion, ajoutez ce lien. »
« Et déplacez cet élément. »
Il vaut mieux les rassembler dans un seul paquet.
L’équipe peut alors effectuer plusieurs modifications pendant un même cycle de travail.
Moins de changement de contexte.
Moins de communication.
Moins de déploiements.
Moins de coût.
2. Prioriser
Tout n’est pas urgent.
Si chaque demande a le statut :
URGENT
alors aucune n’est vraiment urgente.
Il vaut la peine de classer les tâches en :
- critique,
- important,
- planifié,
- cosmétique.
Ainsi l’équipe peut travailler plus efficacement.
3. Réfléchir si la modification nécessite un développeur
Si l’entreprise modifie régulièrement :
- des textes,
- des images,
- des bannières,
- des liens,
- des messages,
peut‑être que le problème n’est pas la vitesse du développeur.
Peut‑être que le problème est l’architecture.
Si chaque changement de contenu nécessite un développeur, il vaut la peine de réfléchir à un CMS ou un panneau d’administration.
Un système bien conçu doit permettre aux personnes du business de gérer elles‑mêmes ce qui n’exige pas l’intervention d’un développeur.
Un bon système doit répondre à la question : qui doit effectuer ce changement ?
C’est un principe de conception très important. Toutes les modifications ne devraient pas revenir au développeur.
Si le marketing peut, de manière autonome :
- changer un texte,
- remplacer une image,
- ajouter un article,
- modifier l’ordre des sections,
il n’a pas de sens d’impliquer un développeur.
Le développeur devrait s’occuper de ce qui requiert ses compétences.
Parmi d’autres choses :
- la création de nouvelles fonctionnalités,
- le développement du système,
- les intégrations,
- l’optimisation,
- la sécurité,
- l’architecture,
- la résolution de problèmes techniques.
Sinon, l’entreprise commence à payer des développeurs pour un travail que l’utilisateur du système pourrait effectuer.
C’est un peu comme engager un mécanicien pour faire le plein. Il sait le faire. Mais en a‑t‑on réellement besoin ?
Quand faut‑il dire : « Faisons‑le autrement » ?
Si la même demande revient régulièrement, il vaut la peine de s’arrêter et de se poser la question :
Pourquoi devons‑nous le faire manuellement à chaque fois ?
Si chaque semaine on demande de modifier le même élément, peut‑être faudrait‑il créer :
- un réglage dans le CMS,
- une configuration,
- un panneau d’administration,
- une automatisation,
- un mécanisme en self‑service.
Le coût unique de création d’une telle solution peut être plus élevé. Mais ensuite chaque modification peut coûter quelques secondes au lieu d’une heure.
C’est la différence entre payer pour chaque changement et investir dans un système qui permet d’effectuer les changements soi‑même.
Micro‑tâches et modèle de collaboration avec un software house
C’est aussi un sujet important pour les clients.
Si la collaboration avec le software house repose exclusivement sur le modèle : « on signale — vous estimez — on accepte — vous exécutez », chaque petite modification peut générer une surcharge organisationnelle.
C’est pourquoi, dans une collaboration continue, les approches suivantes fonctionnent souvent mieux :
- des packs d’heures,
- un abonnement de maintenance,
- une équipe dédiée,
- un backlog de tâches,
- des sprints réguliers,
- des fenêtres de déploiement planifiées.
Cela ne signifie pas que chaque client doit choisir le même modèle. Il s’agit d’adapter la méthode de collaboration au caractère du projet.
Si l’entreprise a besoin d’une modification par mois, un processus complexe peut être inutile. Si l’entreprise envoie 50 tâches par mois, l’absence de processus peut revenir très cher.
Faut‑il facturer chaque modification ?
Ça dépend.
Dans certains projets, comptabiliser précisément chaque minute a du sens. Dans d’autres, cela génère plus d’administration que d’économies.
Il vaut donc la peine de regarder la collaboration dans une perspective plus large.
La question la plus importante n’est pas : « Combien a coûté cette seule modification ? »
La meilleure question est : « Combien nous coûte la manière dont nous gérons toutes les modifications ? »
Si l’entreprise paie 200 zł pour une modification et que, grâce à cela, elle évite des erreurs et a la certitude que tout fonctionne correctement, cela peut être un coût raisonnable.
En revanche, si chaque mois elle paie plusieurs milliers de zł pour des dizaines de micro‑tâches similaires, il vaut la peine de se demander si le problème ne peut pas être résolu de façon systémique.
Les mots les plus coûteux en IT ?
Peut‑être que ce sont : « C’est juste un petit changement. »
Non pas parce que les petites modifications sont mauvaises. Elles sont nécessaires.
Un produit numérique vit. Les besoins des clients changent. Le marché change. Le marketing change. La technologie change. Les modifications sont naturelles.
Le problème commence lorsque l’organisation ne voit pas leur coût cumulatif.
Une petite modification ? — Pas grand‑chose.
Dix ? — Encore peu.
Cent ? — C’est déjà un processus.
Et si de tels processus sont plusieurs ? Soudain, l’entreprise ne dépense plus d’argent pour développer le produit. Elle le dépense pour corriger en permanence des détails.
Au lieu de compter les boutons, comptons le temps
Un développement bien géré d’un produit digital ne consiste pas à empêcher le client de demander de petites modifications.
Il consiste à savoir :
- quelles modifications nécessitent réellement un développeur,
- quelles peuvent être faites par soi‑même,
- quelles vaut‑il mieux automatiser,
- quelles doit‑on regrouper,
- quelles sont vraiment urgentes,
- quelles peuvent être planifiées,
- quelles il vaut mieux résoudre de manière systémique.
Parce que parfois la meilleure réponse à : « Corrigez‑le vite. »
n’est pas : « D’accord, nous le ferons. »
Mais : « Demandons‑nous pourquoi dans un mois nous devrons encore le corriger. »
C’est précisément là que le software house cesse d’être uniquement un exécutant et devient un partenaire technologique. Car un bon partenaire ne se contente pas d’exécuter les tickets.
Il aide aussi à voir que parfois la modification la moins chère n’est pas celle que nous ferons plus vite. La moins chère est celle que nous n’aurons pas à refaire cent fois.
Et voilà pourquoi un bouton « Corrigez‑le vite » peut coûter une heure.
Mais un système bien conçu peut faire en sorte que les cent prochaines modifications de ce type se fassent en quelques minutes par vos soins.
Ce n’est pas une économie sur les développeurs. C’est un investissement dans un meilleur processus, une meilleure architecture et une utilisation plus intelligente du temps de toute l’équipe.
