Le fondateur d’une entreprise d’IA partage comment créer des workflows agentiques pour la livraison de projets et le support client

Cette contrainte est vite devenue un laboratoire expérimental pour la livraison de projets. Lorsqu’on ne peut pas engager plus de monde pour résoudre un problème, chaque décision de projet devient existentielle : est-ce que cela va décupler notre productivité, ou est-ce juste de l’agitation qui donne une impression de progrès ?

Ce filtre impitoyable a révélé des schémas que je ne voyais pas lorsque j’avais le luxe d’ajouter des personnes aux problèmes dans mes deux précédentes startups, que j’ai fondées et développées selon l’ancien modèle de croissance à tout prix. Désormais, après avoir vu plus de 200 entreprises mettre en œuvre l'IA avec le produit de Swan, je repère instantanément les motifs d’échec.

You should also read

• 7 tâches quotidiennes du chef de projet : Que font les PM au quotidien

• Chef de projet stressé ? 10 conseils pour retrouver votre dynamisme

• Le leader en ingénierie IA affirme que les rôles dédiés à la gestion de projet vont disparaître

Pourquoi l’IA fait passer la livraison de projets de la planification à la reconnaissance de schémas et à la rapidité de décision

Le changement le plus frappant concerne la façon dont j’alloue mon temps — c’est presque l’inverse du management de projet traditionnel. Je consacre très peu de temps aux tâches qui monopolisaient autrefois mon attention, comme la planification initiale, les réunions de suivi ou la documentation que personne ne lit. On y reviendra dans un instant.

Voici où va mon attention aujourd’hui :

• 60% vont à la reconnaissance de schémas et à la prise de décision : J’analyse en temps réel ce qui fonctionne sur nos plus de 200 déploiements. Pas de revues mensuelles, mais une veille quotidienne des motifs. Quels déploiements produisent des résultats exponentiels, lesquels stagnent ? Où apparaissent vraiment les goulots d’étranglement, par rapport à où on pensait qu’ils seraient ? Le but est de décider rapidement ce qu’on arrête ou ce sur quoi on double la mise, et ce n’est pas lors d’une revue trimestrielle qu’on y arrive. Pour cela, nous avons un tableau de bord Retool pour la santé client et les alertes sont remontées dans Slack. J’utilise aussi Metabase, où nous avons des analyses produit plus détaillées par client.
• 30% sont consacrés à la conception de boucles de rétroaction : Comment savoir en moins de 48 heures si la mise en place d’une IA fonctionne ? Quels signaux nous disent de pivoter ou de persister ? Je mets en place des "systèmes de détection de rupture", qui permettent de repérer quand une IA sort du cadre ou lorsqu'un workflow n’est pas efficace avant que cela ne tourne à la crise. Pour cela, il est important de fixer un plan clair démarrant par des étapes mesurables et simples. Les chefs de projet traditionnels planifiaient pour la réussite ; moi, je construis des systèmes qui font remonter immédiatement les échecs pour pouvoir les corriger rapidement.
• 10% concerne le véritable "lancement de projet" : Cela avait jadis des allures de point culminant après des mois de préparation. Aujourd’hui, c’est un mardi comme un autre. Nous livrons des versions v1 en continu et traitons le lancement comme le début de l’apprentissage, non comme la fin de la planification. Le lancement, ce n’est plus un succès — c’est simplement la permission de récolter des retours concrets.

Dans un monde dominé par l’IA, l’exécution est rapide et peu coûteuse. Le goulot d’étranglement, c’est la rapidité de décision. Mon rôle a évolué de "faire un plan parfait" à "prendre des décisions rapides à partir de vrais feedbacks". C’est pourquoi je consacre 90% de mon temps à concevoir des systèmes d’apprentissage, pas des systèmes d’exécution.

Dans un monde dominé par l’IA, l’exécution est rapide et peu coûteuse. Le goulot d’étranglement, c’est la rapidité de décision.

Share This Quote on:

• Share on Twitter
• Share on LinkedIn
• Share on Facebook

Amos Bar Joseph

PDG de Swan AI

Comment éliminer le coût de la coordination dans la livraison des projets

Notre passage d’un management de projet traditionnel à une gestion légère n’a pas été un changement de méthodologie mais la suppression de rituels spécifiques qui nous ralentissaient. Voici ce qui a disparu et ce qui l’a remplacé :

Réunions de suivi (40% du calendrier) → Mises à jour asynchrones (désormais 5% du temps)

• Supprimé : Réunions hebdomadaires de suivi de projet avec des diaporamas
• Remplacé par : Brèves mises à jour sur Slack lorsqu’un changement survient, pas selon un calendrier
• Pourquoi cela marche : L’information circule lorsqu’elle est utile, pas quand l’agenda l’impose
• Résultat : 15 heures par semaine récupérées par fondateur

Plans de projet détaillés (2 à 4 semaines en amont) → Définition des résultats attendus (2 à 4 heures)

• Supprimé : Documents de spécifications complets, cartes de flux de travail, matrices de risques
• Remplacé par : Résultat clair souhaité et première expérimentation à mener
• Pourquoi ça fonctionne : Les plans deviennent instantanément obsolètes ; les résultats restent pertinents
• Résultat : Livraison des premières versions en quelques jours, pas en plusieurs mois

Chaînes d'approbation → Droits de décision clairs

• Supprimé : « Demander l’avis de la direction » pour des petites décisions
• Remplacé par : Seuils définis — en dessous de $X ou de Y d'impact, passez à l'action
• Pourquoi ça fonctionne : La rapidité compte plus que la prévention de petites erreurs
• Résultat : Le délai entre décision et action est passé de quelques jours à quelques heures

Revues trimestrielles → Feedback quotidien

• Supprimé : Réunions programmées « voyons l’état d’avancement de ce projet »
• Remplacé par : Indicateurs automatiques qui nous alertent dès qu’un problème survient
• Pourquoi ça fonctionne : On détecte les problèmes au 2e jour, pas au 3e mois
• Résultat : Problèmes corrigés avant qu’ils ne deviennent des crises

Nous sommes passés de 60% de notre temps à coordonner le travail à 90% à le réaliser. Pas parce que nous sommes plus disciplinés, mais parce que nous avons supprimé la taxe de coordination générée par la gestion de projet traditionnelle.

Comment l’IA transforme les rituels de livraison en exigeant un contexte plus riche

La pensée traditionnelle suppose que l’IA réduit la communication humaine. Notre réalité est tout l’inverse : avoir de l’IA dans l’équipe signifie que nous communiquons plus explicitement, car l’IA a besoin de contexte pour être utile.

C’est particulièrement pertinent pour nous, car nous utilisons notre propre produit pour supprimer la « taxe du contexte » — il s’intègre à nos canaux de communication pour collecter et restituer le contexte. Il écoute.

Cela impacte fortement nos rituels. Les projets de satisfaction client en sont un bon exemple. Lorsqu’un client signale un problème ou fait une demande, nos fondateurs communiquent volontairement avec plus de détails que nécessaire entre eux — car nous savons que l’IA capte ces informations.

Concrètement, voici ce que cela change :

Au lieu d’écrire : « Le client X veut la fonctionnalité Y, on en parle demain »

Nous écrivons : « Le client X a demandé la fonctionnalité Y. Contexte : il atteint actuellement une limite à 200 leads/jour, son équipe de 3 SDRs est submergée, et cette fonctionnalité lui permettrait de gérer 500/jour sans embauche. Cela correspond à notre cible PME en phase de montée en charge. Urgence : élevée — le client évalue des concurrents cette semaine. »

Plus tard, quiconque interagit avec ce client — y compris l’IA — aura accès au contexte pertinent.

Cela prend 2 à 3 minutes de plus par échange. Mais cela permet d’économiser des heures sur :

• Réunions d’alignement — l’IA garde tout le monde synchronisé
• Recherche de contexte — l’IA connaît déjà la situation
• Passations — l’IA préserve le contexte à chaque interaction

Lorsque vous considérez l’IA comme un membre de l’équipe devant être constamment informé, vos rituels de communication et de documentation changent fondamentalement — et c’est ainsi que l’IA devient vraiment utile, et pas simplement une fonction parmi d’autres.

Conseil d’Amos

Lorsque vous considérez l’IA comme un membre de l’équipe devant être constamment informé, vos rituels de communication et de documentation changent fondamentalement — et c’est ainsi que l’IA devient vraiment utile, et pas simplement une fonction parmi d’autres.

Pourquoi définir d’abord les rôles humains est essentiel pour une adoption réussie de l’IA

Les échecs d’implémentation d’IA ne proviennent presque jamais d’une insuffisance de l’IA elle-même. Ils surviennent parce que les équipes ne répondent pas à la question la plus fondamentale : « Que doivent réellement prendre en charge les humains dans ce workflow ? »

Voici le schéma que j’observe constamment sur plus de 200 implémentations :

Les équipes passent des semaines à se demander : « L’IA peut-elle gérer cette tâche ? » Elles cartographient le processus actuel, identifient ce que l’IA peut automatiser, conçoivent le système, et le lancent. L’IA fonctionne. Elle peut réaliser de façon fiable 70-80% de la tâche.

Puis tout s’écroule. Non pas parce que l’IA tombe en panne, mais parce que personne n’a défini ce que doivent faire les humains sur les 20 à 30% restants. Deux scénarios se produisent alors :

1. Les humains micro-managent tout. Ils ne font pas confiance à l’IA : ils vérifient chaque décision, transformant ce qui devait être une implémentation d’IA à $20K en un coûteux outil de suggestion. L’équipe s’épuise à contrôler le travail de l’IA.
2. Les humains abandonnent totalement la responsabilité. Ils partent du principe que « l’IA gère » et ne surveillent plus rien. Quelque chose casse ou sort du cadre, et la crise client éclate sans que personne ne s’en rende compte.

Cela s'explique par le fait que nous avons abordé la mise en œuvre de l'IA à l'envers. Nous nous sommes demandé « Que pouvons-nous automatiser ? » au lieu de « Où le jugement humain est-il irremplaçable, et comment peut-on concevoir une IA qui amplifie ce jugement ? »

À la place, débutez chaque projet IA en définissant d'abord le rôle humain. Quelles décisions nécessitent de l'intuition ? Où le contexte est-il critique ? Quels modes d'échec réclament une supervision humaine ? Ensuite, construisez l'IA pour gérer le reste et mettre en avant les bons signaux au bon moment pour la prise de décision humaine.

Avec le recul, cela paraît évident. Mais lorsque l'on s'enthousiasme pour les capacités de l'IA, il est très facile de sauter cette étape et de se concentrer uniquement sur ce que l'IA peut faire — au lieu de concevoir dès le départ la collaboration entre l'humain et l'IA.

Un cadre pratique pour décider de ce que l'IA doit automatiser

J'analyse les décisions d'automatisation selon deux axes : l'impact de l'erreur et la complexité du jugement requis. Cela crée quatre catégories évidentes, que je vais présenter dans un instant.

Lorsque l'on monte en complexité ou en impact, le rôle de l'IA passe de « propriétaire » à « assistant ». Mais il est essentiel de définir à l'avance le rôle de l'IA pour chaque flux de travail — et non après le lancement, quand les humains ne savent pas s'ils doivent faire confiance ou passer outre les décisions de l'IA.

Le cadre ne concerne pas ce que l'IA peut faire techniquement. Il porte sur ce que l'IA doit prendre en charge selon le niveau de risque et le jugement demandé.

Faible impact + faible complexité = automatisation totale

Exemple 1 : Enrichissement de données et recherche

• L'IA récupère les informations sur l'entreprise, l'environnement technologique, les profils sociaux
• Si une erreur s'est glissée, les humains la détectent lors de la relecture
• Aucun jugement requis — il s'agit simplement de collecte de données
• Mise en œuvre : intégrations API, IA structure la sortie, contrôle humain ponctuel

Exemple 2 : Premier scoring et routage des prospects

• L'IA évalue selon des critères ICP définis, oriente vers le flux approprié
• Les erreurs d'aiguillage sont évidentes et facilement corrigées
• La logique est codifiable (taille de l'entreprise, secteur d'activité, signaux de comportement)
• Mise en œuvre : évaluation basée sur des règles + IA, l'humain vérifie les cas limites

Faible impact + forte complexité = IA prépare, humain décide

Exemple : Réponses du support client

• L'IA rédige les réponses selon des cas similaires passés
• Complexité car le ton, le contexte, les cas particuliers sont importants
• Mais faible impact si l'on relit avant l'envoi
• Mise en œuvre : IA rédige, humain relit/édite, on apprend des modifications

Fort impact + faible complexité = automatisé avec garde-fous

Exemple : Envois de messages sortants

• Fort impact car une mauvaise exécution peut nuire à votre marque/marché
• Mais complexité relativement faible — et la qualité est mesurable
• Mise en œuvre : IA génère, validation stricte, arrêt automatique en cas de baisse de performance

Fort impact + forte complexité = piloté par l'humain

Exemple : Changement d'orientation de projet stratégique

• Décider d'abandonner ou d'intensifier une mise en œuvre
• Nécessite la reconnaissance de schémas, dans divers contextes
• Une mauvaise décision coûte cher en ressources perdues ou opportunité ratée
• Mise en œuvre : IA fait remonter les signaux (baisse d'utilisation, retours récurrents), l'humain tranche

Exemple : Négociations clients complexes

• Négociation tarifaire, discussion d'expansion, risques de renouvellement
• Nécessite de décrypter la dynamique relationnelle, le contexte politique, les préoccupations non exprimées
• Se tromper détruit une confiance difficile à regagner
• Mise en œuvre : IA effectue la recherche et la préparation, l'humain gère la discussion

Comment des workflows agentiques ont permis un système de support auto-apprenant en 13 heures

Voici un exemple de la complexité que nous avons gérée grâce aux workflows agentiques dans notre quête de l'automatisation d'une entreprise.

La contrainte : Viser 10M $ de revenus récurrents annuels par employé avec seulement 3 fondateurs signifiait que nous ne pouvions pas résoudre les problèmes en recrutant. Quand les tickets d’assistance ont dépassé 200+/semaine, la réponse traditionnelle — embaucher 2 CSM — n’était pas une option pour nous. Chaque ticket nécessitait l’attention totale d’un fondateur — rechercher la bonne réponse, rédiger le retour, le documenter quelque part. Nous étions submergés.

V1 (semaine 1) : Répondre aux questions connues

Nous avons commencé par le strict minimum : un agent IA sur Slack capable de répondre à environ 20 questions que nous avions déjà documentées dans Notion.

• Outils : Swan AI, Slack, Notion
• Configuration : 6 heures
• Résultat : 15 % des tickets traités
• Nouveau problème : Les clients étaient frustrés de recevoir « Je ne sais pas » comme réponse. Nous continuions à répondre manuellement à 85 % des demandes.

V2 (semaine 2) : Escalader les questions inconnues

Nous avons ajouté une voie d’escalade : l’IA reste dans le fil client, mais nous signale en interne lorsqu’elle ne connaît pas la réponse. Nous répondons, et l’IA transmet notre retour au client.

• Configuration : 3 heures
• Résultat : 35 % de résolution autonome
• Nouveau problème : Nous avons remarqué que nous répondions sans cesse aux mêmes nouvelles questions. Chaque escalade n’enseignait rien à l’IA — elle faisait seulement de la redirection.

V3 (semaine 4) : Apprendre des escalades

Nous avons construit la boucle d’apprentissage. Désormais, lorsque nous répondons à une question remontée, l’IA capture automatiquement la question et la réponse, les structure et les ajoute à la base de connaissances.

• Configuration : 4 heures
• Résultat : 70 % de résolution autonome en deux semaines

Pourquoi cela a fonctionné : Chaque version a pris moins de 6 heures à construire car nous ne visions pas la perfection — nous réagissions à des retours précis. La capacité « d’auto-apprentissage » n’était pas prévue à l’origine. Elle a émergé quand nous nous sommes demandé : « Pourquoi répondons-nous deux fois aux mêmes questions ? »

Aujourd’hui, nous traitons plus de 200 tickets/semaine, 70 % de façon autonome, et notre base de connaissances s’enrichit progressivement à partir des vraies questions clients.

Voici donc mon conseil : lancez le strict minimum pour soulager la douleur immédiate. Observez où cela casse. Ajoutez le minimum de fonctionnalités pour corriger la faille. Répétez. Nous avons construit un système auto-apprenant avancé sans jamais l’avoir planifié dès le départ.

D’autres domaines propices aux workflows agents

Nous utilisons également des workflows « agents » dans :

• Onboarding : Nouveau client → Swan guide l’installation de façon conversationnelle, pose des questions ICP, configure les workflows selon les réponses
• Suivi du succès : Surveille les usages → signale les opportunités d’expansion ou risques → remonte aux fondateurs avec recommandations

Pourquoi les boucles de rétroaction comptent plus que votre choix d’outil IA, et comment les construire

Tout le monde demande : « Quel outil IA devrions-nous utiliser ? » Mauvaise question.

Le plus précieux gain de temps, ce n’est pas un outil — c’est de savoir, sous 48 heures, quand quelque chose casse.

Nous intégrons des boucles de rétroaction à chaque mise en place. Nous suivons :

• Schémas d’escalade : Quand l’IA transfère aux humains, c’est un indicateur qu’elle a besoin d’aide
• Taux de modification : Quand un humain corrige la réponse de l’IA, cela montre que le jugement était faible.
• Indicateurs de résultat : Réunions prises, tickets résolus, etc. — pas seulement l’activité.
• Déclencheurs d’échec : Alertes automatiques quand les performances baissent.

Sans boucles de rétroaction, vous lancez l’IA en espérant que ça fonctionne. Et quand vous réalisez que ça ne marche pas — souvent par des plaintes ou au cours de bilans trimestriels — vous avez perdu des mois.

Avec des boucles de rétroaction, vous repérez les problèmes en quelques jours et les réglez tant qu’ils sont minimes.

Nous avons constaté un vrai impact :

• Support IA : 35 % → 70 % d’autonomie en 2 semaines grâce à l’identification des questions nécessitant de meilleures réponses
• Qualification IA : amélioration de 40 % de la précision en 30 jours en suivant les ajustements humains

Votre choix d’outil IA importe bien moins que votre capacité à détecter ce qui dysfonctionne et à itérer rapidement. Le « véritable outil » qui fait gagner le plus de temps, c’est le système qui vous signale ce qu’il faut corriger avant que cela ne devienne une crise.

Un socle technologique natif IA au service de la livraison autonome de projet

Cela dit, j’ai tout de même quelques essentiels :

• Projets Claude (outil de productivité IA) : Je crée et j’itère sur tous les documents liés au projet dans un projet Claude. Ainsi, le contexte de l’IA s’accumule et elle devient plus intelligente à chaque conversation.
• Shortwave (outils de communication IA) : C’est un nouveau client email conçu pour l’IA avec un agent intégré qui m’aide à retrouver facilement le bon contexte dans tout le fouillis de ma boîte de réception. Il m’aide aussi à rédiger d’excellents emails et à synchroniser les parties prenantes sans devoir changer de contexte ni perdre du temps à retrouver des anciens fils de discussion.
• N8N (logiciel d’automatisation des flux de travail IA) : Je l’utilise pour construire des agents IA connectés à nos outils Retool et Metabase afin de recevoir les mises à jour de projet directement dans Slack.

Pourquoi la gestion de projet évolue vers la gestion de la vélocité

L’IA en gestion de projet évoluera d’une livraison de projet discrète vers une gestion de la vélocité basée sur l’adaptation continue.

Je pense que l’IA va rendre la création et la modification tellement rapides que les projets avec début et fin définis deviendront obsolètes. D’ici à ce qu’un projet de 3 mois soit terminé, les exigences auront changé, les capacités de l’IA auront évolué, et la solution « complète » sera déjà dépassée.

Ce qui remplacera ce modèle, ce sont des cycles d’amélioration continue avec des boucles de rétroaction rapides. Au lieu de « lancer le portail client en T3 », cela deviendra « faire évoluer en continu les interactions client, livrer des changements chaque jour en se basant sur des retours réels ».

Les « gestionnaires de vélocité » optimiseront pour :

• Vitesse de la rétroaction à la correction — pas les dates de livraison
• Fréquence d’itération — pas l’achèvement du projet
• Vitesse d’apprentissage — pas la gestion du périmètre

Le succès sera défini par votre capacité à détecter rapidement les problèmes et à livrer des solutions, non par l’atteinte des jalons prédéfinis.

Les chefs de projet qui survivront développent déjà ce réflexe : livrer une version 1 imparfaite, itérer selon les usages concrets, privilégier la rapidité à la perfection. Ceux qui s’attardent encore sur leurs diagrammes de Gantt ne reconnaîtront plus le métier dans cinq ans.

Pourquoi la vitesse d’itération l’emporte sur la planification — et comment les leaders peuvent livrer plus vite grâce à l’IA

Voici mon conseil : Optimisez pour la vitesse d’itération, pas pour la perfection de l’exécution.

À arrêter : La planification sur plusieurs semaines, les lancements parfaits, la recherche de l’absence totale d’échec.

À commencer : Livrer des versions utiles minimales en quelques jours, construire les boucles de retour d’abord, apprendre de cycles rapides d’itération.

Et rendez cela concret : Réduisez de 75 % la phase de planification de votre prochain projet. Livrez quelque chose d’imparfait cette semaine pour découvrir ce qui compte vraiment. Mesurez votre succès par la rapidité avec laquelle vous passez de « ça a cassé » à « voici la v2 ».

La vitesse d’apprentissage l’emporte toujours sur la profondeur de la planification.

La vitesse d’apprentissage l’emporte toujours sur la profondeur de la planification.

Share This Quote on:

• Share on Twitter
• Share on LinkedIn
• Share on Facebook

Amos Bar Joseph

CEO de Swan AI

Suivez l’actualité

Vous pouvez suivre le travail d’Amos sur l’automatisation des workflows GTM sur LinkedIn et la newsletter Swan. Vous pouvez aussi découvrir Swan et Autonamos, le clone numérique d’Amos.

D’autres entretiens d’experts sont à venir sur The Digital Project Manager !