Lundi matin, 9h07.
Tu ouvres ta boîte mail : 18 messages non lus.
Tu ouvres Teams/Slack : 6 notifications.
Tu ouvres ton outil de tickets : 12 “URGENT” (oui, tous).
Et là, le coup de grâce : quelqu’un te “push” un truc sur la tête.
“Tu peux prendre ça ? C’est rapide.”
“Ajoute juste une petite modif.”
“On en a besoin pour ce soir.”
“Ah et au fait, le client X attend une réponse.”
Dans ta tête, tu sais déjà comment ça finit : tu vas démarrer 6 choses, en terminer zéro, et passer la journée à changer de contexte comme un onglet Chrome en burn-out.
Bienvenue dans le monde du push.
Et si je te disais qu’il existe un réflexe simple — presque contre-intuitif — qui réduit drastiquement ce chaos ?
Un réflexe qui marche en IT, mais aussi en administratif, en contenu, en support, en gestion…
👉 Tirer le travail (pull) au lieu de le pousser (push).
Push vs Pull : la différence en une image mentale
Le push (pousser)
Le travail t’arrive dessus parce que :
- quelqu’un te l’assigne,
- quelqu’un te le balance “au plus vite”,
- un planning a décidé que “c’est maintenant”,
- l’organisation confond “être occupé” et “être efficace”.
Résultat typique :
trop de travail en cours → priorités qui bougent → multitâche → retards → stress → erreurs → encore plus de boulot.
Un push system, c’est une machine à produire… du désordre.
Le pull (tirer)
Le travail n’entre dans “En cours” que si :
- il y a de la capacité,
- un slot s’est libéré,
- et on “tire” l’élément le plus prioritaire depuis une file d’attenteQueueitems en attente devant une étape.Ex : “À valider”, “En review”, “À tester”. claire.
Traduction simple :
On finit avant de commencer.
Ça a l’air banal. En réalité, c’est un super-pouvoir.
Pourquoi le pull réduit le chaos (vraiment)
1) Parce qu’il limite le “trop en cours”
Le chaos naît rarement du volume total.
Il naît du nombre de choses entamées mais non terminées.
Chaque tâche ouverte :
- te coûte de la mémoire mentale,
- te crée une dette de reprise (“où j’en étais déjà ?”),
- multiplie les points de friction (attentes, relances, dépendances).
Le pull force une règle d’or :
✅ 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. bas (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. = travail en cours)
→ moins de dispersion
→ plus de focus
→ plus de finitions.
Et ce n’est pas de la philosophie : c’est mécanique.
2) Parce qu’il stabilise les priorités
Dans un système push, les priorités sont souvent… émotionnelles :
- le dernier qui a parlé,
- le plus insistant,
- le plus “haut placé”,
- le plus stressé.
Dans un système pull, les priorités deviennent visibles et négociables :
- une file “Prêt” (ReadyReadyétat où l’item est suffisamment clair pour être commencé sans découvrir un manque critique au bout de 30 minutes.),
- un ordre clair,
- des règles explicites.
Ça ne supprime pas les urgences.
Ça évite juste que tout soit urgent tout le temps.
3) Parce qu’il réduit le multitâche (et donc les erreurs)
Le multitâche n’existe pas.
Il y a juste du switch rapide entre des tâches inachevées.
Et chaque switch coûte :
- du temps (reconstruire le contexte),
- de la qualité (oublis, raccourcis),
- de l’énergie (fatigue cognitive).
Le pull pousse (sans jeu de mots) vers :
- des boucles plus courtes,
- des tâches finies,
- des retours plus rapides,
- moins de “patch sur patch”.
4) Parce qu’il rend les goulots d’étranglement impossibles à ignorer
Avec le push, on masque les problèmes en empilant :
“Si ça bloque, commence autre chose.”
Avec le pull, un blocageBlocker / Blockedun item “bloqué” ne peut pas avancer pour une raison externe ou interne (dépendance, attente de validation, accès, incident, manque d’info…). se voit :
- la colonne “En attente” grossit,
- une étape sature,
- un rôle devient bottleneckBottleneckl’étape où le flux ralentit systématiquement (queueQueueitems en attente devant une étape.Ex : “À valider”, “En review”, “À tester”. qui grossit, attente récurrente).Souvent : revue de code, validation métier, tests, mise en production, sécurité….
Et quand c’est visible, tu peux enfin agir :
- redistribuer,
- simplifier,
- automatiser,
- changer une règle,
- réduire la taille des items.
Le pull ne supprime pas les problèmes :
il t’empêche juste de les planquer sous le tapis.
Exemples concrets qui parlent à tout le monde
Exemple 1 — Support / Helpdesk
Push : on assigne des tickets en rafale “pour répartir”.
Chacun a 12 tickets ouverts. Personne ne répond vite. Les clients relancent.
Le bruit augmente, la pression aussi.
Pull :
- 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. max par personne (ex : 3 tickets “En cours”)
- on tire le prochain ticket uniquement quand un slot se libère
- escalade claire des urgences (règles explicites)
Résultat : moins de tickets “ouverts depuis 10 jours”, plus de réponses rapides, moins de relances.
Exemple 2 — Dev / Produit
Push : sprint rempli, nouvelles demandes qui arrivent, on “case” en plus, on commence plein de branches, on finit en retard, QA déborde.
Pull :
- on limite le nombre de cartes en dev et en review
- on aide à finir (swarming) au lieu de démarrer
- on tire depuis un backlog prêt, priorisé
Résultat : moins de “presque terminé”, plus de “livré”, cycle timeCycle Timele temps entre “on commence vraiment” et “c’est fini”.Typiquement : entrée dans une colonne “In Progress” → arrivée dans “Done”. plus stable, QA respire.
Exemple 3 — Contenu / Marketing
Push : “On doit publier 12 posts ce mois-ci.”
Donc on lance 12 brouillons. On jongle. Tout sort moyen. Ou en retard.
Pull :
- 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. limité (ex : 2 articles en rédaction, 2 en relecture)
- un article ne rentre en rédaction que si un slot se libère
- politique “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é…” claire (SEO, relecture, visuels)
Résultat : qualité + régularité, moins d’éparpillement, moins de rush de dernière minute.
Exemple 4 — Administratif / Gestion
Push : on traite “au fil de l’eau”, on ouvre 15 dossiers, on attend des infos, on relance, on oublie, on re-relance.
Pull :
- file “Prêt” (dossiers complets)
- 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. limité sur “en traitement”
- une colonne “En attente” assumée (et visible)
Résultat : moins d’oubli, moins de relances inutiles, meilleure prévisibilité.
“Ok, mais si on ne push plus… on ne fait plus rien ?”
C’est l’objection classique.
Le pull ne veut pas dire :
- “on attend tranquillement”
- “on refuse tout”
- “pas de deadlines”
- “chacun fait ce qu’il veut”
Le pull, c’est :
- une discipline d’entrée (quand et comment une tâche devient “en cours”),
- une discipline de capacité (combien de choses on accepte en parallèle),
- des règles explicites (urgences, priorités, qualité).
En vrai, c’est plus exigeant que le push.
Parce que tu dois assumer tes choix au lieu d’empiler.
Comment passer au pull en 60 minutes (version simple)
Étape 1 — Visualise le flux
Même simple :
- À faire
- En cours
- Terminé
Ajoute une colonne “En attente” si tu as souvent des blocages.
Étape 2 — Mets une limite de WIP
Exemples qui marchent bien :
- solo : 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. “En cours” = 1 ou 2
- équipe : 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. “En cours” = nombre de personnes (ou un peu moins)
Le but : que “En cours” fasse légèrement mal quand on dépasse.
Étape 3 — Fixe une règle de pull (très claire)
“On ne tire une nouvelle carte que si on a terminé (ou libéré un slot).”
Et on tire la carte la plus prioritaire d’une file “Prêt”.
Étape 4 — Fais un mini rituel de replenishment
10 minutes, 2 fois par semaine, par exemple :
- qu’est-ce qui est “Prêt” ?
- dans quel ordre ?
- qu’est-ce qu’on refuse / reporte ?
C’est là que tu tues le chaos à la source : l’entrée.
Le vrai bénéfice caché : tu récupères de l’oxygène
Un système push te vole ton souffle : tout est urgent, tout est entamé, tout te poursuit.
Un système pull te rend un truc précieux :
- de la place mentale,
- une sensation de maîtrise,
- et surtout : de la prévisibilité.
Et dans un monde où tout s’accélère, la prévisibilité… c’est du luxe.
Conclusion : “Stop starting, start finishing”
Si tu devais retenir une seule phrase :
Arrête de commencer. Commence à finir.
Le pull, ce n’est pas une méthode compliquée.
C’est un changement de réflexe : on protège la capacité, on limite le travail en cours, et on tire le prochain item au bon moment.
Et quand tu fais ça, le chaos n’a plus autant de prises.
Bonus SEO (Yoast)
- Expression clé principale : tirer le travail pull vs push
- Méta description : Push ou pull ? Découvrez pourquoi “tirer le travail” (Kanban) réduit le chaos, limite le multitâche et stabilise les priorités, avec des exemples IT, support, contenu et administratif.
