J’ai construit l’IA pour récupérer mon temps. Je suis devenu le goulot d’étranglement.

Je dirige Z Digital Agency, je suis co-fondateur et COO de Sommelier.bot, et j’anime des round-tables privés Cyber-Sécurité et IA pour la plupart des grandes entreprises européennes. Trois rôles, trois fenêtres sur ce qui se passe vraiment avec la révolution IA.

Il y a trois ans, j’ai commencé à construire avec l’IA. Depuis décembre 2025, je construis des systèmes IA sérieusement. Pas « utiliser Claude avec MCP pour rédiger des emails plus vite » sérieusement. Sérieusement au sens : des agents, des pipelines, de la mémoire, des flywheels, des automatisations autonomes, une couche opérationnelle entière conçue pour faire tourner des parties de l’agence sans que je sois assis au milieu.

Vingt-quatre mois plus tard, j’ai plus de systèmes en route que je ne l’aurais jamais imaginé. Et je me sens plus fatigué qu’avant qu’aucun d’eux n’existe. Pas fatigué de taper. Fatigué d’une façon plus difficile à nommer : la fatigue spécifique d’être la partie la plus lente de quelque chose que vous avez conçu pour être rapide.

Je ne pense pas que ce soit un échec personnel. Je ne pense pas être le seul dans ce cas.

Je pense que la majorité de ce que l’industrie de l’IA vend aujourd’hui suppose l’exact opposé de ce qui se passe réellement une fois que les systèmes commencent à fonctionner.

Alors laissez-moi expliquer ce que j’ai eu faux.

Chaque machine à gagner du temps nous a rendus plus occupés

Ce n’est pas de la spéculation. C’est un pattern documenté sur cinquante ans, et il compte ici parce qu’il vous dit ce à quoi vous attendre de la prochaine vague avant qu’elle n’arrive. Quatre penseurs, aucun n’a touché à l’IA, qui décrivent exactement ce que je vivais :

• Staffan Linder (1970). Quand une économie s’enrichit, les gens ne deviennent pas plus oisifs. Ils deviennent plus occupés. Plus une société s’enrichit, plus l’argent qu’une heure peut générer augmente, et plus il devient coûteux de gâcher cette heure. La richesse n’achète pas le temps. Elle le rend plus rare, parce qu’elle relève le prix de chaque minute que vous n’exploitez pas. Je l’ai ressenti personnellement dans le mois qui a suivi la mise en route des premiers systèmes. Plus chaque heure portait de levier, plus une heure vide devenait insupportable.
• Hartmut Rosa (2005). Chaque outil qui fait gagner du temps ne réduit pas votre charge de travail. Il élève ce qu’on attend de vous. L’email n’a pas ramené la correspondance à cinq messages par jour. Il a fait passer le volume normal à cinquante. J’ai construit un système qui pouvait générer dix fois le contenu que je produisais avant. Je n’ai pas obtenu dix fois plus de temps libre. J’ai obtenu l’attente silencieuse, surtout venue de moi-même, que je devais désormais produire dix fois plus de sortie. Rosa appelait cela une pente glissante : vous courez plus vite et le sol bouge avec vous, donc vous ne prenez jamais réellement d’avance.
• Jonathan Crary (2013). Une économie 24/7 colonise lentement le sommeil, la dernière partie de la journée qui ne produit rien. Mes agents tournent à 3h du matin. Ils ne se fatiguent pas, ils ne s’arrêtent pas, ils n’attendent pas que je me réveille. J’ai construit un système explicitement conçu pour ne jamais dormir, et quelque part dans cette conception, j’ai cessé de remarquer que moi, j’en ai encore besoin.
• Josef Pieper (1948). La voix la plus ancienne de cette liste défendait que le vrai loisir n’est pas un temps de récupération entre deux tâches. C’est la capacité de s’asseoir avec quelque chose pour lui-même, sans l’optimiser. Cette capacité exige du mou. Les systèmes IA, laissés sans supervision, sont extraordinairement bons pour supprimer le mou, parce que le mou ressemble à du gaspillage pour un système qui optimise le débit.

Quatre époques différentes, un seul pattern. Chaque accélération précédente a été vendue comme un chemin vers plus de loisir. Aucune n’a livré cela.

Pourquoi l’IA casse le pattern au lieu de simplement le répéter

Voici où le cadre plus ancien, conçu pour la technologie au rythme humain, commence à se tendre. La pente glissante de Rosa suppose qu’un humain fixe encore le rythme au moins d’un côté de l’équation : la personne qui répond au mail plus rapide, l’ouvrier qui tient le rythme de la machine plus rapide. L’IA supprime cette hypothèse.

Un agent qui rédige, décide et exécute en quelques secondes ne relève pas seulement la barre de la vitesse à laquelle un humain doit répondre. Il retire l’humain entièrement de ce côté de la boucle. Le système n’a plus besoin de moi pour tenir son rythme en temps réel. Il déroule une stratégie, teste cent variantes et livre une décision pendant que je suis encore en train de lire le premier paragraphe d’un brief.

Ce n’est pas une version plus rapide du problème du mail. C’est un problème d’une catégorie différente, parce que la chose qui est optimisée n’est plus bornée par ma capacité à penser, lire, ou réagir.

Posez-vous la question, honnêtement : au rythme auquel vos systèmes IA produisent des sorties en ce moment, êtes-vous encore réellement en train d’évaluer ce qu’ils livrent, ou êtes-vous en train d’approuver ? Les deux se ressemblent sur le moment. Ce n’est pas du tout la même chose. Tous les développeurs qui ont vu leur Claude Code demander la permission à chaque geste au début, puis beaucoup moins ensuite… savent de quoi je parle.

Quand tout devient possible, je suis la contrainte

Voici la partie qui m’a pris le plus de temps à accepter.

Je pensais que la contrainte de mon business était le temps, puis c’était le budget, puis c’était le talent. L’IA a supprimé les trois, plus vite que je ne m’y attendais, et ce qui est resté au milieu du chemin n’était rien de tout ça.

C’était moi.

Quand un système peut générer cent versions de quelque chose dans le temps qu’il me fallait pour en rédiger une, la décision de savoir laquelle compte, quelle direction poursuivre, quelle chose mérite mon attention réelle, ne devient pas plus rapide. Si quoi que ce soit, elle devient plus lente, parce qu’il y a maintenant cent options au lieu d’une seule étape suivante évidente. La machine a accéléré. Mon jugement, non. Et il ne peut pas. Le jugement n’est pas un problème de calcul. C’est un problème humain, qui tourne sur le même système nerveux qu’il a toujours eu.

J’ai passé des mois à me sentir coupable de cela. J’ai supposé qu’il me fallait juste bouger plus vite, décider plus vite, tenir le rythme. Ce que j’ai fini par comprendre, c’est que « tenir le rythme » n’a jamais été le vrai but. Le système n’a pas besoin que je corresponde à sa vitesse. Il a besoin que je sache, plus lentement et plus délibérément que le système n’opère, laquelle des cent choses qu’il vient de produire vaut réellement la peine d’être poursuivie.

Être le goulot d’étranglement n’est pas l’échec. Confondre ce rôle avec un échec, oui.

La friction était ce qui me protégeait de moi-même

Il y a un second effet auquel je ne m’attendais pas, et qui a probablement fait plus de dégâts que la fatigue.

Quand construire quelque chose prenait des semaines, la friction elle-même imposait une forme de filtre. On ne démarrait pas un projet sans y avoir réfléchi, parce que démarrer coûtait cher. Cette friction faisait un travail silencieux et peu glorieux : elle tuait les mauvaises idées avant qu’elles ne vous coûtent quoi que ce soit.

Retirez la friction et quelque chose d’étrange se produit. Parce que construire est maintenant rapide, bon marché, presque sans friction, l’instinct devient que tout doit être construit, et construit maintenant. Une landing page ici. Une automatisation là. Un content engine par là. Une douzaine de choses à moitié construites qui tournent en parallèle parce que démarrer l’une d’entre elles ne coûtait presque rien.

J’ai personnellement brûlé de vrais mois et de vrai budget sur des projets qui étaient techniquement faciles à lancer et qui ne valaient pas la peine d’être lancés en premier lieu. La facilité de démarrer m’a fait sauter la question plus difficile de savoir si je devais. Construire vite sans penser vite ne produit pas plus de choses terminées. Ça produit plus de choses inachevées, à un volume qui devient à terme sa propre taxe sur l’entreprise, payée en distraction plutôt qu’en cash. Ce qui, curieusement, rend la chose plus facile à ignorer et plus difficile à arrêter.

La question que j’aurais dû me poser avant d’appuyer sur go pour chacun de ces builds : si ça fonctionne, qu’est-ce que je dois arrêter de faire pour lui laisser de la place ? Je ne me la suis jamais posée. J’ai construit quand même. Six mois plus tard, j’avais six systèmes et la capacité d’attention pour un.

La priorisation est la seule compétence qui capitalise vraiment maintenant

Si construire n’est plus le goulot d’étranglement, et si penser clair sous l’abondance est le problème plus difficile, la compétence qui compte le plus a discrètement changé.

Ce n’est pas le prompt engineering. Ce n’est pas savoir quel modèle choisir pour quelle tâche. C’est la priorisation, au sens le plus ancien et le moins excitant du terme : la discipline de décider ce qu’on ne fera pas, et de s’y tenir.

Cela paraît trop simple pour être la réponse, mais j’ai vu la chose se répéter assez souvent pour y faire confiance. Les personnes et les entreprises qui avancent vraiment avec l’IA ne sont pas celles qui font le plus d’expériences. Ce sont celles qui sont prêtes à tuer neuf idées IA sur dix avant qu’elles ne consomment une seule heure de build, et prêtes à dire non à leur propre enthousiasme. C’est la version la plus difficile de cette compétence, parce que l’enthousiasme est réel et que les idées sont souvent bonnes.

La règle que j’applique maintenant à la fois à l’agence et chez Sommelier.bot : je ne démarre pas un build tant que je ne peux pas nommer le client ou le workflow spécifique qui sera moins bien loti si je ne le fais pas. Pas « ce serait sympa d’avoir ». Moins bien loti. La plupart des idées échouent à ce test. C’est le but du test.

Un « système IA » n’est pas le build. C’est ce qui survit au contact des clients réels et construit un flywheel à chaque usage.

C’est la distinction que je pense que la plupart des gens qui construisent avec l’IA en ce moment ratent, moi y compris pendant longtemps.

Construire quelque chose qui fonctionne techniquement n’est pas la même chose que construire un système. Un pipeline qui fonctionne, un agent qui tourne, une automatisation astucieuse : rien de tout ça n’est un système. C’est un prototype avec des valeurs de production correctes.

Un système existe à l’instant où il survit au contact de quelque chose de réel : des clients réels qui l’utilisent, des données réelles qui le traversent, des boucles de feedback réelles qui vous disent ce qui fonctionne et ce qui ne fonctionne pas. C’est le point où un build cesse d’être une démo et commence à capitaliser, où chaque cycle rend le suivant légèrement meilleur parce qu’il y a du vrai signal qui le nourrit, pas juste mes propres hypothèses sur ce qui devrait fonctionner.

La plupart de ce qu’on appelle « un système IA » aujourd’hui n’atteint jamais ce point. C’est un build qui fonctionne en isolation, qu’on montre une fois, puis qui reste là, techniquement fonctionnel et pratiquement inerte, parce que personne ne l’a poussé assez loin pour que de vrais clients y touchent ou que de vraies données s’y accumulent. J’en ai construit plusieurs comme ça moi-même. Ils me semblaient être des progrès sur le moment. Avec le recul, c’étaient des répétitions coûteuses de la chose que je ne m’étais pas vraiment engagé à finir.

Combien des choses IA que vous ou votre équipe avez construites ces douze derniers mois ont dépassé cette ligne ? Si la réponse honnête est « moins que ce que j’aimerais avouer », vous êtes sur la tendance, pas hors d’elle.

La partie la plus difficile du travail IA n’a jamais été la partie IA. C’est la discipline peu glorieuse qui consiste à porter une seule chose assez loin au-delà de la phase de build excitante pour qu’elle se mette à générer ses propres preuves, ses propres clients, son propre flywheel. Ça prend beaucoup plus de temps que de construire la chose, de loin. Et c’est la partie où presque personne ne veut s’installer, parce qu’elle est plus lente, moins nouvelle et ne ressemble pas à de l’innovation pendant qu’on la fait.

Si vous construisez un site, un outil en ligne ou du contenu : réfléchissez en amont à la façon dont cela travaille avec votre système et permet des effets de capitalisation. Si ce n’est pas le cas, c’est du bruit, au mieux.

La métrique que personne ne suit : la bande passante humaine

Voici la revendication inconfortable que je poserais devant n’importe quelle équipe dirigeante qui pèse un rollout IA agressif :

Le compute n’est pas votre contrainte. Le coût par token n’est pas votre contrainte. Votre contrainte, c’est la bande passante finie, non négociable, biologiquement fixée, des humains encore responsables du jugement, de la supervision et de la reddition de comptes à l’intérieur du système.

Oui, vous serez tenté à l’avenir d’externaliser cela aussi vers des agents (agent Q&A, agent de validation, même un agent CEO), mais sans quelqu’un vers qui pointer du doigt à la première catastrophe, vous ferez marche arrière sur tout.

Toutes les conversations de déploiement IA auxquelles j’ai participé (les miennes incluses) tournent autour du débit, du volume de sortie, de la réduction des coûts. Presque aucune ne pose la question plus difficile : qu’est-ce qui arrive aux gens qui sont censés contempler la sortie, pas seulement la traiter ? Le mou de Pieper, soixante-dix-huit ans plus tard, reste la variable manquante de chaque plan de déploiement que je lis.

Si votre stratégie IA se mesure purement en heures économisées ou en sortie multipliée, vous optimisez la mauvaise variable. La bonne variable, c’est de savoir si les humains responsables de l’entreprise peuvent encore réellement suivre, questionner et endosser ce que le système est en train de faire, au rythme auquel il le fait.

Ce n’est pas un argument contre l’IA. C’est un argument contre le fait de prétendre que le rythme de vos systèmes peut durablement dépasser le rythme de votre jugement, et que l’entreprise fait encore sens au bout du compte.

Ce que je fais différemment maintenant

Je n’ai pas résolu la fatigue. Je ne pense pas qu’elle disparaisse complètement quand on opère à ce rythme, et j’ai arrêté d’attendre qu’elle le fasse. Ce qui a changé, c’est ce que je mesure et ce que je me permets de démarrer :

• L’automatisation n’est JAMAIS l’objectif, c’est le sous-produit d’une bonne IA. La haute qualité (3x au minimum) est le vrai objectif.
• L’IA rend votre travail meilleur, en agissant comme un vrai sparring partner, en challengeant vos mots vagues et buzzy.
• Mon filtre est devenu : est-ce que ça capitalise ? Si ça ne sert pas le système, je peux dire non avec confiance.
• Il devrait devenir plus intelligent sans moi, grâce à un système construit selon mes besoins. Chaque jour, il scanne mes sources d’information de confiance (youtube, blogs, sites d’info…), extrait ce qui est intéressant, le compare à ce qu’on a déjà dans le système (agents, skills, connaissances, couches de mémoire), et décide de manière autonome ce qu’il faut résumer et injecter dans la base de connaissances, en demandant des clarifications sur les faits ambigus.
• Je me concentre sur le système, pas sur les sorties brillantes. Croyez-moi, j’ai construit 21 sites d’outils brillants en mars… Construisez d’abord le système, puis augmentez sa portée (outils et agents) et son flywheel (mémoire, connaissance auto-capitalisante).

Les machines ne vont pas ralentir. Cela est certain, et prétendre le contraire est une forme de déni. La seule variable réellement sous mon contrôle, c’est à quel point je choisis délibérément ce qui mérite de tourner à cette vitesse, et à quel point j’admets honnêtement que le rythme lui-même n’allait jamais me faire gagner de temps. Il allait seulement relever le prix de le gâcher.

Si tout cela ressemble au rythme de votre propre année, je préférerais une conversation directe plutôt que vous envoyer un dashboard de plus. Contactez-nous.