Pourquoi Hindigo ne te montrera jamais de liste

L’idée de départ tient en une phrase : ne jamais montrer à quelqu’un tout ce qu’il a à faire — seulement le prochain geste, un seul. Simple à énoncer. Beaucoup plus difficile à tenir dans la durée qu’il n’y paraît, et c’est précisément cette difficulté qui en fait la règle la plus importante de Hindigo.

Une règle qui se trahit par petites touches

Ce n’est presque jamais une décision frontale du genre « ajoutons une liste ». C’est plus sournois : un aperçu de ce qui arrive ensuite, une barre de progression, un petit compteur « il en reste 3 ». Chacune de ces idées semble raisonnable prise seule — utile, même. Et chacune, ajoutée, aurait discrètement annulé le principe de départ.

Imagine une réunion produit tout à fait ordinaire. Quelqu’un propose d’ajouter un petit indicateur « 2 sur 5 » en haut de l’écran, pour que la personne sache où elle en est dans sa journée. L’intention est bonne : donner un sentiment d’avancement, motiver. Personne dans la pièce ne pense « ajoutons une liste ». Et pourtant, ce chiffre fait exactement ce qu’une liste fait : il annonce qu’il existe un ensemble de tâches, avec une fin qu’on n’a pas encore atteinte. C’est ce type de glissement, jamais spectaculaire, qui use une contrainte de design bien plus sûrement qu’une décision frontale.

Le problème n’est pas que ces idées soient mauvaises en soi. Ailleurs, dans presque n’importe quel autre logiciel, plus d’information et plus de visibilité sont un bien par défaut. Le souci, c’est que les personnes pour qui Hindigo est pensé vont moins bien, pas mieux, quand elles voient l’ensemble du tableau. Le blocage au démarrage ne se résout pas avec plus d’information — il se résout avec moins.

Ce que la charge cognitive a à voir là-dedans

Ce n’est pas qu’une intuition de design : ça s’appuie sur un mécanisme cognitif assez bien documenté. La mémoire de travail — celle qui garde activement en tête ce sur quoi on est en train de réfléchir — ne traite bien qu’un nombre restreint d’éléments à la fois. Face à une liste de dix tâches affichées ensemble, le cerveau ne les aborde pas une par une dans l’ordre : il doit d’abord les comparer entre elles pour décider laquelle mérite d’être commencée en premier. Cette comparaison est elle-même une tâche cognitive, et une tâche coûteuse.

Pour quelqu’un qui a l’énergie disponible, ce coût passe inaperçu — la priorisation se fait presque automatiquement. Pour quelqu’un déjà en difficulté pour démarrer, ce même coût s’ajoute directement au blocage plutôt que de l’alléger. La liste, censée aider à s’organiser, devient l’obstacle supplémentaire entre l’intention et le premier geste. C’est un renversement qui surprend souvent en dehors du contexte du TDAH ou de la charge mentale élevée : plus d’information n’aide pas toujours à décider, elle peut aussi rendre la décision elle-même plus difficile à prendre.

Il y a aussi un effet plus discret, proche de ce que la psychologie appelle l’effet Zeigarnik : une tâche non terminée reste activement présente à l’esprit, même quand on ne la regarde pas. Une liste de tâches visibles n’est donc jamais neutre — chaque ligne non cochée occupe une part de l’attention, en continu, même pendant qu’on essaie de se concentrer sur autre chose. Multipliée par dix ou quinze tâches, cette présence en fond devient une forme de bruit mental permanent, indépendante de la volonté d’agir.

Le vrai test n’est pas « est-ce utile ? »

Presque toute fonctionnalité peut se justifier comme utile. C’est un mauvais filtre. Le test qui fonctionne est plus étroit et plus inconfortable à appliquer : est-ce que cette fonctionnalité permet de voir plus d’une chose à la fois ? Si oui, elle est suspecte par défaut, pas seulement dans les cas extrêmes.

Est-ce que ça recrée, même discrètement, la vue d’ensemble qu’on essaie de retirer ?

« Utile » n’est pas la barre — presque n’importe quoi peut passer ce test-là. Une liste d’archives consultable à la demande semble utile. Un résumé hebdomadaire des tâches accomplies semble utile. Un bouton « voir tout » discret dans un menu secondaire semble presque anodin. Chacune de ces idées a été proposée en interne à un moment ou un autre ; chacune a été refusée pour la même raison, jamais parce qu’elle manquait d’utilité, mais parce qu’elle recréait, même en périphérie de l’écran, la possibilité de voir plus d’une chose à la fois.

Ce que ça change concrètement dans l’app

Dans l’usage réel, cette règle se traduit par une boucle très courte : capturer une intention, recevoir un seul geste minuscule à accomplir, le marquer fait, puis — seulement à ce moment-là — recevoir le suivant. Jamais de vue d’ensemble entre les deux. Jamais de bouton « voir la suite » qui court-circuiterait la séquence. La personne qui utilise l’app ne sait pas, au moment où elle regarde son écran, s’il reste un geste ou quinze — et c’est précisément ce qui rend chaque geste également accessible, sans hiérarchie de charge à évaluer avant de commencer.

Ce choix a un coût assumé : on ne peut pas, dans Hindigo, consulter d’un coup d’œil tout ce qui reste à faire dans sa journée. Pour quelqu’un habitué aux outils de planification classiques, ça peut d’abord sembler être un manque. Ce n’est pas un oubli — c’est la fonctionnalité elle-même. La contrainte n’est pas ce que l’app ne fait pas encore ; c’est ce qu’elle refuse de faire par principe.

Pourquoi une todo-list classique ne suffit pas ici

Une todo-list bien conçue résout deux problèmes réels : ne rien oublier, et savoir où on en est. Ce sont des problèmes de mémoire et d’organisation, et pour beaucoup de monde, une liste claire suffit largement à les régler. Mais le blocage que Hindigo cible n’est ni un problème de mémoire ni un problème d’organisation — c’est un problème d’initiation. La personne sait très bien ce qu’elle doit faire ; ce qui manque, c’est le pont entre le savoir et le faire.

Une liste, même parfaitement tenue, ne construit pas ce pont. Elle peut même l’éloigner : plus la liste est complète et bien rangée, plus l’écart entre « tout ce qui est prévu » et « ce qui a été fait » devient visible — et c’est précisément cet écart visible qui nourrit le blocage plutôt que de le résoudre. Retirer la liste ne retire pas l’information ; ça retire la comparaison permanente entre l’ampleur de la tâche et l’énergie disponible pour la commencer.

Écrire les interdits, pas seulement l’intention

Ce qui aide vraiment, ce n’est pas de se souvenir de la philosophie de départ — elle s’érode sous la pression d’un planning chargé, comme n’importe quelle bonne intention. Ce qui aide, c’est d’écrire les interdits noir sur blanc : jamais de liste, jamais de streak, jamais de compteur de retard, jamais de rouge. Une fonctionnalité candidate se teste contre cette liste explicite avant d’être envisagée, pas après coup une fois qu’elle est déjà à moitié construite et qu’il est tentant de la garder.

C’est une discipline différente de celle qu’on associe d’habitude au développement produit. Ce n’est pas « qu’est-ce qu’on peut ajouter ? » mais « qu’est-ce qu’on refuse d’ajouter, même quand ça semble justifié ? ». La contrainte la plus importante d’un produit n’est pas celle qu’on écrit dans la spec — c’est celle qu’on doit continuer à refuser de trahir, fonctionnalité après fonctionnalité, réunion après réunion, y compris quand l’idée du moment semble particulièrement raisonnable.

L’application Hindigo applique cette règle sans exception : jamais plus d’un geste visible, jamais une vue d’ensemble imposée. Le pouvoir du plus petit pas ne fonctionne que si rien ne vient le noyer dans une liste plus large — c’est précisément ce que cette règle protège.