L’idée la plus simple et la plus puissante (et pourtant contre-intuitive)
Il y a une phrase que j’aurais aimé entendre plus tôt dans ma vie pro :
“Ton problème n’est pas de manquer d’idées. Ton problème, c’est que tu en démarres trop.”
Et je sais déjà ce que tu penses.
“Oui bon… merci Captain Obvious. On fait ce qu’on peut. On a des urgences. Des demandes. Des tickets. Des mails. Des notifs. Des gens.”
Justement.
Parce que cette idée — arrêter de commencer, commencer à finir — est simple à comprendre, mais terriblement contre-intuitive à appliquer.
Et quand tu la comprends vraiment, elle agit comme un interrupteur : tu ne regardes plus ton travail pareil.
1) Le piège : “On est productifs” (alors qu’on est juste occupés)
Je vais te décrire une scène. Dis-moi si tu la reconnais.
Lundi matin. Tu ouvres ton outil de tickets, ton Slack/Teams, tes mails.
Tu as déjà 8 sujets dans la tête avant ton premier café :
- “Je réponds vite à ce mail, sinon je vais oublier.”
- “Je commence cette tâche, histoire de lancer la machine.”
- “Je prends ce ticket, c’est rapide.”
- “Je fais un début de spec, au moins c’est avancé.”
- “Je check juste ce bug, 5 minutes max.”
À midi, tu as fait plein de choses.
À 18h, tu es rincé.
Et pourtant… rien n’est vraiment terminé.
Ce n’est pas un manque de volonté.
C’est un mécanisme humain : commencer donne une sensation immédiate de progrès.
Commencer, c’est rassurant.
Finir, c’est risqué.
Finir implique :
- choisir,
- renoncer à autre chose,
- se confronter à la qualité (“est-ce que c’est assez bien ?”),
- livrer (“donc être jugé”),
- gérer les détails pénibles.
Alors on “avance” en ouvrant 12 chantiers.
Et on appelle ça… du travail.
2) Le paradoxe contre-intuitif : pour aller plus vite, il faut faire moins
Le Kanban (et plus largement la gestion de flux) a une obsession qui a l’air presque insultante dans un monde d’urgence :
Réduire le travail en cours.
(Limiter le WIPWIPle nombre d’éléments actuellement en cours dans ton système (ton board).En Kanban, le WIP est une variable de contrôle : on le limite volontairement. : Work In ProgressWIPle nombre d’éléments actuellement en cours dans ton système (ton board).En Kanban, le WIP est une variable de contrôle : on le limite volontairement.)
Quand tu limites le nombre de choses “en cours”, tu fais un truc étrange :
tu ralentis volontairement le démarrage de nouvelles tâches.
Et là ton cerveau hurle :
“Mais on va prendre du retard ! On va bloquer ! On va perdre du temps !”
Sauf que… ce que tu appelles “gagner du temps” en commençant plus, c’est souvent l’inverse :
- tu augmentes les interruptions,
- tu multiplies les context switches,
- tu crées des dépendances invisibles,
- tu repousses les validations,
- tu empiles des demi-livrables.
Résultat :
tu as beaucoup de “presque fini”, et très peu de “fini-fini”.
Or dans la vraie vie, seul le “fini” a de la valeur.
Un ticket “à 90%” ne résout rien.
Une feature “presque prête” ne rapporte rien.
Un article “en brouillon” ne génère aucun trafic.
Une facture “presque envoyée” n’est pas payée.
3) Pourquoi c’est si puissant ? Parce que le “fini” libère le système
Quand tu finis quelque chose, il se passe un truc magique :
- tu libères de l’espace mental,
- tu réduis le stress (“c’est sorti de ma tête”),
- tu débloques des gens (“je peux avancer, maintenant”),
- tu rends visible l’avancement réel,
- tu réduis l’empilement.
Et surtout : tu rends ton système prévisible.
La prévisibilité, c’est le luxe ultime.
Pas la vitesse brute.
Un flux prévisible, c’est ce qui permet de dire :
“Ce ticket sera livré jeudi.”
Sans trembler.
Et ça, que tu sois dev, support, RH, marketing ou admin :
tout le monde comprend la valeur de “je sais quand ça finit”.
4) Quatre histoires (très réalistes) où “commencer à finir” change tout
A) Dev / IT : la feature éternelle
Tu as une feature “simple” qui traîne depuis deux semaines.
Pourquoi ? Parce qu’elle a été commencée, puis interrompue par :
- un bug prod,
- une demande urgente,
- une réunion,
- une amélioration “vite fait”,
- une question d’un collègue.
Au final, tu as :
- 3 branches ouvertes,
- 2 MR en attente,
- 1 test incomplet,
- 1 bout d’UI pas raccord.
La feature “avance”, mais ne sort jamais.
Solution “commencer à finir” :
- Tu limites à 1 ton nombre de sujets en cours.
- Tu passes en mode : “je termine avant de reprendre autre chose”.
Tu vas livrer plus vite et tu vas réduire les bugs.
Parce que l’esprit n’est pas fait pour garder 12 puzzles ouverts.
B) Support : la file d’attente qui grossit malgré les réponses
Côté support, on croit souvent que la performance, c’est :
“répondre vite”.
Sauf que répondre vite n’est pas résoudre vite.
Tu peux répondre à 50 tickets en une journée…
et n’en résoudre que 5.
Parce que tu demandes des infos, tu relances, tu attends, tu reprends, tu perds le fil.
Solution “commencer à finir” :
- Tu crées une colonne “En attente client” séparée (hors WIPWIPle nombre d’éléments actuellement en cours dans ton système (ton board).En Kanban, le WIP est une variable de contrôle : on le limite volontairement. ou WIPWIPle nombre d’éléments actuellement en cours dans ton système (ton board).En Kanban, le WIP est une variable de contrôle : on le limite volontairement. très différent).
- Tu limites le nombre de tickets “en cours réel” (ceux où tu fais quelque chose).
- Tu te forces à clôturer avant de prendre le prochain.
Résultat : moins de dispersion, moins de “tickets zombies”, plus de résolutions.
C) Contenu : 12 brouillons, zéro publication
En création de contenu, le piège est encore plus sournois.
Parce que commencer, c’est agréable : idées, plan, intro, titre.
Et finir, c’est :
- couper,
- simplifier,
- illustrer,
- relire,
- publier.
Donc on accumule des brouillons.
Solution “commencer à finir” :
- Tu limites à 2 articles maximum en “production”.
- Le reste va en “Backlog d’idées” (pas en cours).
- Tu définis une “Definition of DoneDefinition of Doneconditions explicites pour considérer un item terminé.Ex : tests passés, PR mergée, doc mise à jour, déployé, validé…” : texte + image mise en avant + meta + publication planifiée.
Ton blog ne grossit pas avec des idées.
Il grossit avec des publications.
D) Administratif : le royaume du “je m’en occupe”
Factures, devis, dossiers, relances, documents…
L’admin, c’est le cimetière des tâches commencées “vite fait”.
Tu as les fichiers, tu as la moitié des infos, tu as ouvert le document…
mais tu n’as pas envoyé.
Et tant que ce n’est pas envoyé, ton cerveau te le rappelle en tâche de fond.
Solution “commencer à finir” :
- 30 minutes par jour, “finition pure” : rien de nouveau, uniquement clôturer.
- Tu traites les tâches jusqu’au bout : envoyer, classer, archiver.
Ton niveau de stress descend sans même que ta charge baisse.
5) La règle d’or : “Terminer = franchir la dernière barrière”
Le vrai “fini” n’est pas “j’ai codé”.
C’est “c’est en prod” (ou livré, validé, publié, clôturé).
Dans presque tous les métiers, le dernier 10% coûte 50% du temps :
- validations,
- tests,
- retours,
- ajustements,
- alignements,
- mise en forme,
- communication.
Et c’est précisément pour ça qu’on l’évite.
Donc, “commencer à finir” veut dire :
organiser ton système pour réussir ce dernier 10%.
6) La méthode simple (Kanban-friendly) pour appliquer ça demain
Étape 1 — Mets ton travail sur un flux visible
Tu n’as pas besoin d’un outil parfait.
Un tableau suffit :
- Backlog
- À faire
- En cours
- À valider / En review
- Terminé
Le détail important : séparer “En cours” et “À valider”.
Parce que beaucoup de choses meurent dans la zone grise du “presque fini”.
Étape 2 — Fixe une limite de WIP (et tiens-la)
Commence brutalement simple :
- En cours : 2 max (ou 1 si tu veux sentir la magie)
- À valider : 2 max
Oui, ça va créer une frustration au début.
C’est normal : tu vas voir la réalité du système.
Si “À valider” est plein, tu n’ajoutes pas de “En cours”.
Tu aides à valider. Tu débloques. Tu termines.
Étape 3 — Installe une politique : “On n’ajoute pas, on finit”
Le réflexe à entraîner :
Quand on te demande un nouveau truc, ta réponse n’est pas “oui”.
Ta réponse, c’est : “ok, qu’est-ce qu’on stoppe ou qu’est-ce qu’on termine d’abord ?”
C’est la phrase la plus saine du monde professionnel.
Elle transforme les demandes en arbitrages, au lieu de les transformer en dette.
Étape 4 — Définis “Terminé” (vraiment)
Écris-le. Affiche-le. Applique-le.
Exemples :
- Dev : merge + tests + déployé + notes de version
- Support : problème résolu + client confirmé (ou délai expiré) + ticket clôturé
- Contenu : publié + image + meta + partage planifié
- Admin : envoyé + archivé + statut mis à jour
Sans définition, “Terminé” devient une impression.
Et une impression, ça se négocie à l’infini.
7) La punchline : ton système ne manque pas de capacité, il manque de finition
Souvent, on croit manquer de temps.
En réalité, on manque de :
- focus,
- limites,
- règles,
- courage de dire non,
- obsession du “done”.
Et c’est là que le principe devient universel.
Parce qu’il ne parle pas d’IT, de Scrum, ou de post-its.
Il parle d’un truc humain :
On se sent mieux en ouvrant des portes.
On avance vraiment en les refermant.
Alors oui, c’est contre-intuitif.
Mais c’est précisément pour ça que ça marche.
La prochaine fois que tu te surprends à dire :
“Je vais juste commencer ça…”
Essaie cette alternative :
“Je vais d’abord finir ce que j’ai commencé.”
Et regarde ton monde devenir plus calme.
Plus clair.
Plus prévisible.
Et, paradoxalement…
plus rapide.
