Le Kanban, pivot du système

On a vu jusqu’ici comment maîtriser ce qui entre dans le système grâce aux inboxes, puis comment réserver le calendrier à ce qui doit avoir lieu à un moment précis. Il reste maintenant tout ce qui ne relève pas directement d’une contrainte temporelle : les tâches que l’on peut choisir d’accomplir à différents moments, selon le contexte et les priorités.

C’est, à mon avis, tout l’intérêt d’un système de productivité. Il ne doit pas seulement stocker une liste de choses à faire : il doit permettre de choisir l’action la plus pertinente à un instant donné, sans devoir reconstruire toute sa réflexion à chaque fois. En bref, il doit aider à optimiser son énergie.

Le cœur de mon système est donc un Kanban. Si vous n’en avez jamais entendu parler, le principe de base est tout ce qu’il y a de plus simple : imaginez des post-it qui passent d’une colonne à une autre à mesure que le travail avance. La méthode vient à l’origine de l’industrie automobile japonaise, mais elle s’adapte très bien à une organisation personnelle, et est un grand classique de beaucoup de sytèmes d’organisation.

L’outil importe assez peu. Notion, Trello, Miro ou beaucoup d’autres applications permettent de construire un Kanban convenable. À titre personnel, j’utilise un système entièrement sur mesure, créé à l’aide du vibe coding, mais ce n’est absolument pas une obligation. La plupart des outils du marché sont suffisamment flexibles pour mettre en place ce que je vais décrire.

Une précision importante avant de commencer : il s’agit ici d’un système de productivité personnel. On peut s’en inspirer pour organiser un couple, une famille ou une petite équipe, mais chaque règle présentée dans cet article est d’abord pensée pour une seule personne. Cela change beaucoup de choses, notamment dans la définition des contextes et dans la façon de décider qu’une tâche est actionnable.

Quatre cas pour suivre le fonctionnement du système

Pour rendre les principes plus concrets, je vais utiliser quatre tâches tout au long de l’article :

• Organiser le repas de Noël pour dix personnes ;
• Finaliser un projet d’analyse de données pour un client ;
• Faire sa lessive hebdomadaire ;
• Installer une étagère dans le salon.

Ces exemples sont volontairement très différents. Certains sont professionnels, d’autres personnels ; certains se règlent rapidement, d’autres demandent plusieurs étapes et dépendent de personnes extérieures. Pourtant, ils peuvent tous être décrits et suivis avec la même structure, et c’est ce qui fait la force du sytème.

Ce qui définit une tâche : la DoD

Le plus petit dénominateur commun du système, c’est la tâche. Mais un simple intitulé ne suffit pas toujours à comprendre ce que l’on cherche réellement à accomplir. « Lessive », « étagère » ou « projet XYZ » donnent une direction, sans indiquer clairement où se trouve la ligne d’arrivée.

Ce qui caractérise vraiment une tâche, c’est donc sa DoD, pour Definition of Done, ou définition de « terminé ». Je conserve ici cet anglicisme venu du développement informatique parce qu’il est court, largement compréhensible et décrit précisément ce dont on a besoin : l’état concret dans lequel la tâche pourra être considérée comme achevée.

Une DoD peut être très ambitieuse (“Déménager au Japon”) ou très modeste(“Ranger le frigo”), il ne faut pas avoir de complexe à ce sujet, ou se dire que l’on s’attaque à quelque chose de trop grand ou trop petit. La seule vraie question est : qu’est-ce qui devra être vrai pour que je puisse affirmer que cette tâche est terminée ?

Appliquons cette question à nos quatre exemples :

• Plutôt que « organiser le repas de Noël », la DoD pourrait être : « Le repas est sur la table, les courses sont rangées et les invités sont installés. »
• Plutôt que « terminer le projet d’analyse », on pourrait écrire : « Le client a validé le mail de fin de prestation et la facture a été payée. »
• Plutôt que « lessive », la tâche devient : « Le linge a été lavé, séché et repassé, et il reste suffisamment de lessive pour le prochain cycle. »
• Plutôt que « installer une étagère », on peut préciser : « L’étagère est installée sans être bancale, les livres et la décoration sont en place, les emballages ont été déposés à la déchèterie et le manuel de montage a été scanné puis sauvegardé dans le cloud. »

Cette définition ne constitue pas une planification exhaustive. Elle n’oblige pas à prévoir dès le départ toutes les étapes ni tous les problèmes possibles. Elle permet simplement d’anticiper le déroulé général, de mieux comprendre où l’on va et, surtout, de ne pas abandonner une tâche à 90 % en oubliant les dernières finitions.

La DoD aide aussi à repérer les tâches trop larges. Si la définition de « terminé » devient interminable ou réunit plusieurs résultats indépendants, il peut être judicieux de créer plusieurs tâches. À l’inverse, il n’est pas nécessaire de découper chaque geste du quotidien en dix cartes différentes. Le bon niveau de détail est celui qui vous aide réellement à avancer.

Parfois, la DoD restera un peu floue, notamment au début d’un sujet que l’on connaît mal. Ce n’est pas grave. Il faut toujours faire l’effort de la formuler avec les informations disponibles, quitte à la préciser plus tard. Une définition imparfaite est déjà plus utile qu’un titre vague dont on ne sait jamais vraiment quoi faire.

La description de la tâche

La DoD décrit l’arrivée ; la description, elle, rassemble les informations utiles en chemin. On peut y prendre toutes sortes de notes : une idée, une contrainte, une adresse, le compte rendu d’un échange, une liste de dimensions ou les raisons qui ont conduit à une décision.

Il est particulièrement pratique d’utiliser un outil qui accepte des liens, des images et, éventuellement, une intégration avec Google Drive ou un service similaire. Dans l’exemple de la tâche de montage de l’étagère, on peut par exemple joindre une photo du mur, les dimensions disponibles et le lien vers le modèle envisagé. Pour le projet d’analyse, on peut conserver le lien vers le dossier partagé et rappeler les principaux interlocuteurs.

L’objectif n’est pas de recréer un système de stockage dans le Kanban. Les documents volumineux et les fichiers de référence peuvent rester dans leur espace habituel. La tâche doit surtout servir de point d’entrée : quand je l’ouvre, je dois retrouver rapidement le contexte nécessaire et savoir où sont les ressources dont j’ai besoin.

Il faut également éviter que la description devienne un cimetière de notes. Une information obsolète peut être supprimée ou clairement marquée comme telle. Une décision importante mérite d’être formulée proprement. Le Kanban doit réduire l’effort nécessaire pour reprendre une tâche, pas l’augmenter en obligeant à relire une conversation confuse de trente lignes.

Le statut : la colonne du Kanban

Le statut d’une tâche correspond à la colonne dans laquelle elle se trouve. Mon système repose sur des statuts simples, mais ils doivent être utilisés avec beaucoup de rigueur. En voici une définition succincte, que je détaillerai par la suite :

• Actionnable : la prochaine action permettant de progresser vers la DoD peut être réalisée, ou au moins commencée, immédiatement. Cela ne veut pas dire qu’il faut la faire tout de suite, seulement que rien ne l’empêche.
• Snoozed : la tâche répond aux mêmes exigences qu’une tâche actionnable, mais elle ne pourra ou ne devra être reprise qu’à partir d’une date future.
• En attente : la tâche est bloquée par une autre personne, une livraison, une décision ou n’importe quel élément extérieur.
• À archiver : la DoD est atteinte. La tâche est terminée, mais reste visible jusqu’au prochain rituel d’archivage.
• Prochain sprint : la tâche n’est pas encore suffisamment claire ou mûre pour devenir actionnable, mais elle mérite d’être conservée pour une prochaine revue.

Cette classification doit décrire la réalité, pas le souhait. Une tâche ne reste pas « Actionnable » simplement parce qu’elle est importante si, dans les faits, vous attendez une réponse. Inversement, une tâche ne doit pas être placée « En attente » uniquement parce que vous n’avez pas envie de vous en occuper.

La valeur du tableau vient précisément de cette honnêteté. En regardant la colonne « Actionnable », je dois pouvoir choisir une tâche et commencer sans découvrir une condition cachée au bout de quelques secondes.

Les tâches dans la colonne « Actionnable »

Une tâche actionnable doit d’abord posséder un contexte. C’est un concept central dans mon système. Le contexte indique avec qui, où ou dans quelles conditions la tâche peut avancer.

Les contextes les plus évidents ressemblent à « avec telle personne », « à la maison » ou « au bureau ». Ils peuvent aussi être plus spécifiques : « en voiture » pour regrouper des appels à passer sur un trajet, « avec un ordinateur » pour les tâches impossibles à effectuer depuis un téléphone, ou « au magasin » pour plusieurs achats à réaliser au même endroit.

À titre personnel, j’utilise également un contexte « brainstorming ». Ce n’est ni un lieu ni une personne, mais plutôt un mode mental : il regroupe les sujets sur lesquels je dois réfléchir librement avant de pouvoir décider de la suite. Cette catégorie me convient, mais elle ne sera pas forcément utile à quelqu’un d’autre.

C’est justement pour cela que les contextes sont personnels. Ils doivent refléter votre vie, vos déplacements, vos outils et votre façon de travailler. Comme les inboxes, ils évolueront avec le temps. Vous pouvez en ajouter lorsqu’un besoin récurrent apparaît et en retirer lorsqu’ils ne permettent plus de faire un choix utile. L’outil choisi doit rendre ces ajustements simples.

Une tâche actionnable doit ensuite contenir une prochaine action, formulée de façon concrète. Il ne s’agit pas de répéter le titre de la tâche, mais de décrire le prochain geste visible qui la fera progresser. « Avancer sur le projet » est trop vague ; « envoyer à Thierry un mail pour lui demander le budget validé par la directrice » est immédiatement exploitable.

On peut noter plusieurs actions à l’avance lorsque la suite est claire. Il n’est pas interdit d’anticiper un peu. La plus importante reste toutefois la première, car c’est elle qui rend la tâche véritablement actionnable. Si je ne sais pas quelle est la prochaine action, la carte n’est pas prête à rester dans cette colonne.

Une fois l’action réalisée, je la coche. S’il en existe une autre qui peut commencer immédiatement, elle devient la prochaine action. Sinon, la tâche change de statut : elle peut partir en attente d’une réponse, être reportée à une date précise ou rejoindre la colonne « À archiver » si sa DoD est atteinte.

Je conserve l’historique des actions passées. Il permet de documenter le travail, de retrouver une information et de comprendre rapidement ce qui a déjà été tenté. C’est particulièrement utile sur les tâches longues ou professionnelles, mais même un projet personnel peut bénéficier de cette trace.

En option, j’ajoute aussi une date de « dernière action » lorsque j’ai avancé de façon significative sans terminer la tâche. C’est un bon moyen de voir les sujets récemment actifs. Quand beaucoup de choses sont ouvertes en parallèle, cette date rappelle que plusieurs chantiers ont réellement progressé, même si aucun n’a encore atteint sa DoD.

Pour nos quatre exemples, les prochaines actions pourraient être les suivantes :

• Repas de Noël : « Chercher à l’aide d’une IA un menu compatible avec les contraintes végétariennes », dans le contexte « Avec un ordinateur ».
• Projet d’analyse : « Envoyer un mail à Thierry pour lui demander le budget validé par la directrice », dans le contexte correspondant à l’ordinateur ou au travail.
• Lessive : « Réunir le linge et lancer la machine », dans le contexte « À la maison ».
• Étagère : « Aller au magasin de bricolage », dans le contexte « Heures ouvrées » ou « Au magasin », selon la façon dont vous préférez organiser vos filtres.

Les contextes ne servent donc pas seulement à décrire les tâches. Ils permettent de filtrer le tableau en fonction de la situation présente. Si je suis chez moi pendant trente minutes, je peux afficher ce qui est actionnable à la maison. Si je vais voir une personne, je peux consulter les sujets à traiter avec elle. Le Kanban cesse alors d’être une longue liste abstraite et devient un outil de décision.

Les tâches dans la colonne « Snoozed »

Le statut « Snoozed » est un peu particulier, mais son principe est simple : la tâche est prête à être actionnée, avec un contexte et une prochaine action, sauf qu’elle ne doit réapparaître qu’à partir d’une certaine date.

Cette colonne évite de polluer « Actionnable » avec des tâches sur lesquelles il n’est pas pertinent d’agir aujourd’hui. Sans elle, le tableau finit par présenter en permanence des cartes qu’il faut lire puis ignorer. Cette répétition crée du bruit et réduit la confiance dans le système.

Idéalement, une automatisation (que l’on peut mettre en place de façon assez simple sur la plupart des outils du marché) fait passer la tâche de « Snoozed » à « Actionnable » lorsque la date choisie est atteinte. Le report n’est alors pas une façon d’oublier le sujet : c’est une décision explicite de le rendre de nouveau visible au bon moment.

Voici comment nos exemples pourraient temporairement rejoindre cette colonne :

• Repas de Noël : la tâche est reportée au jour où le dessert pourra être récupéré chez le traiteur, sachant que tout le reste est déjà organisé et planifié.
• Projet d’analyse : une réunion intermédiaire avec le client est prévue dans cinq jours et la prochaine action dépendra nécessairement de son issue. La tâche peut être snoozée jusqu’à cette date plutôt que surveillée quotidiennement.
• Lessive : une fois le linge étendu, la tâche est reportée de douze heures, au moment où il devrait être sec et prêt à être repassé.
• Étagère : si l’achat est volontairement repoussé au début des soldes, la carte peut réapparaître à cette date.

Je trouve utile de trier cette colonne par « date de retour » dans « Actionnable ». On voit ainsi ce qui va revenir automatiquement et à quelle échéance. Ce petit aperçu permet d’anticiper la charge à venir sans encombrer la liste des choix présents.

Il faut néanmoins éviter d’utiliser « Snoozed » comme un bouton de fuite. Reporter chaque semaine une tâche inconfortable ne règle rien. Si une carte revient constamment sans avancer, le problème se situe peut-être dans sa DoD, sa prochaine action, son contexte ou sa pertinence même. Le système doit alors provoquer une décision, pas entretenir indéfiniment le report.

Les tâches dans la colonne « En attente »

Une tâche passe « En attente » lorsqu’elle ne peut plus avancer sans un élément extérieur. Le point le plus important est de noter la date de mise en attente. Cette date indique depuis combien de temps le blocage existe et aide à décider quand une relance devient nécessaire.

Dans mon Kanban, je trie ces tâches de la plus récemment mise en attente à la plus ancienne. Ce choix permet de suivre naturellement le déroulé des échanges. On peut aussi préférer faire remonter les plus anciennes si l’objectif principal est de repérer les blocages qui durent ; l’essentiel est de disposer de la date et d’adopter un ordre cohérent.

Il faut également indiquer clairement de qui ou de quoi on attend un retour. « En attente » ne suffit pas. Une formulation comme « En attente de la validation de Julien depuis le 12 juillet » permet de comprendre la situation immédiatement et de relancer la bonne personne sans devoir relire toute la carte.

Une tâche en attente n’a plus de contexte actif, puisque ce n’est plus à vous d’accomplir la prochaine action. Son ancien contexte peut rester dans l’historique si cela aide à documenter le travail, mais elle ne doit plus apparaître dans les filtres des tâches que vous pouvez réaliser maintenant.

Nos exemples donnent des situations très classiques :

• Repas de Noël : la tâche attend qu’un cousin confirme dans le groupe WhatsApp familial s’il mange bien certains légumes.
• Projet d’analyse : la tâche attend que Julien confirme la bonne réception du rapport.
• Étagère : le modèle choisi est en rupture de stock et la tâche attend le mail du magasin annonçant son retour.

La lessive, elle, offre moins naturellement un cas d’attente extérieure. Si la machine tombe en panne et qu’une intervention est planifiée, la tâche pourrait attendre le réparateur. Dans le déroulé ordinaire, le temps de séchage correspond plutôt à « Snoozed », puisque l’on connaît approximativement le moment où l’action suivante redeviendra possible.

Cette distinction entre « Snoozed » et « En attente » est importante. Dans le premier cas, c’est surtout une date qui commande le retour de la tâche. Dans le second, c’est un événement extérieur dont le moment reste souvent incertain. Confondre les deux rend les relances et les automatisations beaucoup moins fiables.

Les tâches dans la colonne « À archiver »

Cette colonne est la plus simple : la DoD a été atteinte. Le repas a eu lieu, le client a validé la prestation et payé la facture, le linge est rangé ou l’étagère est complètement installée. Il n’y a plus de prochaine action à définir.

Je ne supprime pourtant pas immédiatement la tâche. Je la place dans « À archiver » pour deux raisons :

• Il est toujours possible de s’être trompé. Une tâche peut revenir dans « Actionnable », « Snoozed » ou « En attente » si l’on découvre qu’un élément manque réellement à sa DoD.
• Mon système repose aussi sur une logique de sprints. Au cours d’un rituel dédié, les tâches terminées sont revues puis réellement archivées. J’expliquerai ce fonctionnement plus tard.

Je trie cette colonne par date de fin, de la plus récente à la plus ancienne. Elle offre ainsi un aperçu immédiat du travail accompli depuis la dernière revue. Ce n’est pas seulement satisfaisant : cette liste permet aussi de vérifier que les résultats annoncés sont bien complets avant de les faire disparaître de la vue courante.

Le mot « archiver » est important. Une tâche terminée peut contenir des décisions, des liens ou un historique utile. La conserver permet de retrouver plus tard la date d’une action, le modèle acheté, la personne contactée ou la façon dont un problème avait été résolu. Tout garder éternellement n’est pas nécessaire, mais supprimer par défaut fait perdre une mémoire qui peut avoir de la valeur.

La colonne « Prochain sprint »

La colonne « Prochain sprint » accueille ce qui n’est pas encore actionnable, ni même toujours parfaitement clair, mais que je ne veux pas oublier. Elle sert de zone intermédiaire entre une idée capturée dans une inbox et une tâche correctement préparée.

Une carte peut y rester parce que sa DoD doit encore être précisée, parce que le projet n’est pas prioritaire dans le sprint actuel ou parce qu’il faudra prendre une décision lors de la prochaine revue. Elle ne doit en revanche pas se faire passer pour une tâche actionnable : tant que sa prochaine action et son contexte ne sont pas définis, elle n’a rien à faire dans la colonne correspondante.

Cette colonne sera traitée pendant un rituel de revue lié aux sprints. Chaque élément devra alors connaître une issue claire : être préparé et rendu actionnable, être reporté, retourner dans une inbox si une réflexion complémentaire est nécessaire, ou être abandonné s’il n’a finalement plus d’intérêt.

Je reviendrai en détail sur les sprints et leurs rituels dans un autre article. Pour l’instant, il suffit de retenir que « Prochain sprint » n’est pas un débarras permanent. C’est une file d’attente destinée à être revue à un moment précis.

Bonus : faut-il séparer le professionnel et le personnel ?

En ce qui me concerne, j’utilise un seul Kanban pour mes tâches professionnelles et personnelles. J’ai ajouté un champ spécifique, distinct des contextes, qui me permet de filtrer instantanément l’un ou l’autre de ces univers.

Cette séparation logique me paraît plus pratique que deux systèmes complètement indépendants. Ma capacité d’attention reste unique : une contrainte personnelle peut affecter ma journée de travail, et une échéance professionnelle peut réduire le temps disponible à la maison. Une vue commune me permet donc de faire des choix avec l’ensemble de la situation en tête.

Pour autant, il n’existe pas de règle absolue. Vous pouvez avoir besoin de deux Kanbans distincts pour des raisons de confidentialité, de droits d’accès, de connexion aux outils de votre entreprise ou simplement de préférence personnelle. Ce n’est pas un problème. Dans ce cas, essayez au moins de conserver des règles cohérentes entre les deux systèmes et une façon simple d’obtenir une vision d’ensemble lorsque vous en avez besoin.

Le champ « professionnel ou personnel » ne remplace pas les contextes. « Professionnel » décrit une sphère de vie ; « avec Thierry », « au bureau » ou « avec un ordinateur » décrivent les conditions dans lesquelles une action peut avancer. Mélanger ces deux dimensions produit des filtres moins utiles.

En résumé

Un Kanban personnel efficace ne repose pas sur un grand nombre de colonnes ni sur un outil sophistiqué. Il repose sur quelques distinctions tenues avec rigueur.

Chaque tâche doit exprimer clairement le résultat attendu grâce à sa DoD. Si elle est actionnable, elle doit posséder une prochaine action concrète et un contexte pertinent. Si elle ne peut pas avancer, le tableau doit expliquer pourquoi : une date future, une attente extérieure ou un besoin de clarification lors du prochain sprint.

Le mouvement entre les colonnes est aussi important que le contenu des cartes. Après chaque action significative, il faut se demander si la tâche est toujours actionnable, si elle attend désormais quelque chose, si elle doit être reportée ou si sa DoD est atteinte. C’est cette mise à jour régulière qui maintient le tableau fiable.

Quand ce fonctionnement devient naturel, le Kanban joue réellement son rôle de pivot. Les inboxes alimentent le système, le calendrier protège le temps contraint et le tableau présente le travail qui peut avancer. Vous ne choisissez plus dans une liste indistincte de choses à faire : vous choisissez parmi des actions réellement possibles, dans le contexte où vous vous trouvez.