2. Déléguer sans renoncer

Mon, 13 Apr 2026 12:00:00 +0000

Dans cette série : Self-custody, mais jusqu’où ?

La question n’est plus d’utiliser l’IA mais de savoir jusqu’où la laisser entrer.

Le débat sur l’IA se fige trop souvent dans une alternative paresseuse. D’un côté, l’enthousiasme sans frein : tout brancher, tout automatiser, tout accélérer. De l’autre, la posture de retrait : garder ses distances, se défier de tout, et se flatter d’une austérité supposée plus lucide.

Ni l’une ni l’autre ne tient très longtemps dans la vie ordinaire.

La question sérieuse est plus exigeante : quels types de délégation peut-on consentir sans perdre la maîtrise de sa pratique ?

Nous disposons ici d’une ressource précieuse : nous avons déjà appris, dans d’autres domaines, qu’il ne suffit pas qu’un système soit performant pour qu’il soit légitime. Il faut encore savoir qui contrôle quoi, dans quelles limites, et avec quelle réversibilité.

Appliquée à l’IA, cette intuition doit maintenant devenir une discipline.

Assistance, délégation, abandon

Le premier geste consiste à distinguer ce que l’époque tend à confondre.

L’assistance est simple : l’outil aide, suggère, reformule, accélère. Il augmente la capacité d’agir sans déplacer le centre de décision.

La délégation commence lorsque l’outil ne se contente plus d’aider. Il garde le contexte, réordonne, filtre, prépare, surveille, présélectionne, ou déclenche certaines opérations dans un périmètre défini.

L’abandon commence lorsque la délégation devient trop vaste, trop opaque ou trop confortable pour rester réellement gouvernée. Le système continue alors à fonctionner à notre service, mais il devient de plus en plus difficile d’expliquer ce qu’il fait exactement, pourquoi nous lui faisons confiance, et ce qui se passerait s’il fallait reprendre la main.

Ce n’est pas la même chose. Et pourtant, beaucoup d’usages actuels glissent de la première situation vers la deuxième — parfois vers la troisième — sans jamais le dire franchement.

Le vrai test : la facilité

Le problème de la délégation n’apparaît pas d’abord dans les cas extrêmes. Il apparaît dans les cas faciles.

Ce n’est pas lorsque le système propose de signer une transaction absurde que la vigilance se joue le plus souvent. C’est lorsque, jour après jour, il devient normal qu’il lise à notre place, trie à notre place, relie à notre place, surveille à notre place et prépare notre travail avant même que nous nous y mettions.

Là encore, Morin aide à voir plus juste. Le danger n’est pas seulement l’erreur spectaculaire ; c’est la dépendance qui se forme à bas bruit, dans la continuité du service rendu. Nous finissons alors par confondre l’augmentation de notre puissance avec le dessaisissement progressif de notre présence.

Autrement dit : ce qui menace l’autonomie n’est pas toujours l’hostilité. C’est souvent la douceur.

Où commence la responsabilité individuelle

Les protocoles, les builders et les fournisseurs d’outils ont un devoir d’information, de lisibilité, de bornage et, lorsqu’ils le peuvent, de prudence dans le design. Mais ils ne peuvent pas porter seuls la charge d’éduquer des utilisateurs ou des opérateurs décidés à tout déléguer sans discernement.

Il existe donc une responsabilité proprement individuelle qu’il faut réhabiliter.

On trouve une version particulièrement nette de cette préoccupation chez Vitalik Buterin, lorsqu’il défend un usage local-first, compartimenté et fortement borné des LLM. L’intérêt de ce setup n’est pas de fournir un modèle universel. Il est de rendre visible une chose plus profonde : à mesure que l’IA devient un milieu d’action ordinaire, la question décisive n’est plus seulement celle de la puissance des modèles, mais celle des limites que nous acceptons (ou non) de poser à leur délégation.

Mais la pratique ne consiste ni à devenir paranoïaque ni à revenir à une austérité héroïque. Elle consiste à se demander, avec un peu de fermeté : qu’est-ce que je veux vraiment gagner ? et qu’est-ce que je refuse de perdre en l’obtenant ?

Et cette question est plus difficile qu’il n’y paraît. Parce que nous voulons presque tous la même chose : davantage de vitesse, davantage de clarté, moins de friction, moins de fatigue, plus de continuité. Le problème est que ces gains ont un prix. Et ce prix n’est pas toujours payé en données. Il se paie parfois en habitudes de dépendance.

Une discipline minimale de délégation

Il n’existe pas de stack parfaite. Il existe en revanche une discipline minimale, assez simple pour être pratiquée sans se transformer en programme de pureté.

1. Garder le noyau du jugement

Tout ce qui touche à l’interprétation décisive d’une situation doit rester sous garde directe. On peut se faire aider pour explorer, cartographier, comparer, résumer. Mais le moment où une lecture devient un arbitrage doit demeurer identifiable.

2. Borner l’action avant d’augmenter l’assistance

Le vrai danger n’est pas qu’un système soit intelligent. C’est qu’il soit intelligent et bien branché. Plus l’accès s’étend — messagerie, base documentaire, automatisation, wallet, exécution — plus les bornes doivent être nettes.

3. Préférer les couches lisibles aux couches magiques

Un bon outil n’est pas seulement celui qui marche. C’est celui dont le rôle peut être raconté simplement. S’il faut cinq explications pour comprendre ce qu’il voit, ce qu’il retient, ce qu’il prépare, ce qu’il peut déclencher et ce qui l’arrête, la délégation est déjà trop opaque.

4. Traiter le confort comme un signal d’alerte

Plus un système devient fluide, plus il faut se demander ce qu’il rend invisible. Le confort est un bénéfice réel. Il est aussi, très souvent, le moment où la vigilance décroît.

5. Organiser la reprise en main avant d’en avoir besoin

Une délégation saine doit rester réversible. Si l’on ne peut plus débrancher un outil sans perdre l’intelligibilité de sa pratique, l’accès à ses informations essentielles ou la possibilité d’agir sans lui, alors l’outil tient déjà une place excessive.

Un mini-workflow plus utile qu’une stack idéale

Pour beaucoup d’usages quotidiens, une discipline de délégation suffit déjà à faire une différence nette.

À garder sous garde directe

L’interprétation décisive d’une position, les arbitrages qui engagent du capital, de la réputation ou une relation, ainsi que les accès critiques : clés, secrets, permissions à large rayon d’action.

À assister sans trop de risque

Recherche exploratoire, cartographie d’un sujet, résumé, reformulation, comparaison, structuration de notes.

À déléguer seulement dans un périmètre borné

Veille, monitoring, préparation de brouillons, classements, automatisations à faibles conséquences.

À ne jamais déléguer sans friction explicite

Signature, mouvements de fonds, messages externes, actions irréversibles, modifications de permissions ou de paramètres critiques.

Ce second texte voulait rendre la question praticable

Nous ne sortirons pas de ce moment par le refus pur. Nous n’en sortirons pas non plus par l’abandon ravi.

Il nous faut autre chose : une manière d’habiter l’IA sans lui remettre d’un seul geste ce qu’elle rend justement plus difficile à discerner.

Cela suppose moins une pureté qu’une tenue. Moins une morale grandiose qu’un art des limites.