Sobhan Daliry, CPO & Responsable de la stratégie IA chez Pipefy – Série d’interviews

Sobhan Daliry, CPO & Responsable de la stratégie IA chez Pipefy, est un cadre expérimenté en produit et technologie qui dirige la stratégie IA de l’entreprise depuis 2023, contribuant à transformer les flux de travail métier traditionnels en processus de plus en plus intelligents et autonomes. Tout au long de sa carrière, Daliry a combiné stratégie produit, transformation organisationnelle et leadership technologique au sein de startups et d’entreprises établies. Avant de rejoindre Pipefy, il a fondé et occupé le poste de PDG de Polen.me et a passé plus de cinq ans en tant que PDG/CPO de NZN, où il a mené le redressement de l’entreprise et la stratégie produit. Ses fonctions antérieures comprennent Directeur de la gestion produit chez PSafe, Chef de produit chez Peixe Urbano, ainsi que des postes couvrant les services numériques, les télécommunications, le conseil et le développement commercial chez Oi/Telemar, Claro, AIRCOM International et Planeta Tecnologia.

Pipefy est une plateforme mondiale de gestion des processus et d’IA conçue pour aider les organisations à automatiser et orchestrer leurs flux de travail. Fondée en 2015, l’entreprise est passée d’une plateforme d’automatisation de processus sans code à un environnement d’orchestration centré sur l’IA qui réunit les agents IA, les flux de travail, les formulaires, les portails, les applications, les données, l’analyse, la messagerie et les intégrations. Sa plateforme permet aux équipes de créer et de gérer des agents IA à l’aide du langage naturel et d’outils sans code tout en maintenant la gouvernance d’entreprise, la sécurité et la visibilité. Les capacités IA de Pipefy comprennent des agents capables d’interpréter des documents, d’exécuter des tâches de flux de travail, de soutenir la prise de décision, d’interagir avec des systèmes externes et d’orchestrer des processus dans des domaines tels que la finance, les ressources humaines, les achats, les opérations client et la conformité.

Votre carrière vous a conduit de l’ingénierie télécom dans des entreprises comme Claro et Oi à la direction produit chez Peixe Urbano et PSafe, en passant par le poste de PDG/CPO chez NZN, la création de Polen.me, et aujourd’hui à la direction du produit et de la stratégie IA chez Pipefy. Comment cette évolution a-t‑elle façonné votre façon de concevoir des produits IA qui résolvent de vrais problèmes opérationnels plutôt que de simplement mettre en avant de nouvelles technologies ?

Le secteur des télécoms m’a appris que l’infrastructure doit fonctionner à chaque fois, à grande échelle, sans aucune marge pour « ça fonctionne surtout ». Un appel interrompu n’est pas un échec de démonstration, c’est un client qui s’en va. Cette mentalité — la fiabilité avant la nouveauté — ne m’a jamais quitté. Chez Peixe Urbano et PSafe, j’ai appris la leçon inverse : la rapidité avec laquelle les produits grand public vivent ou meurent dépend de leur capacité à résoudre un problème réel et ressenti aujourd’hui, et non d’une hypothèse théorique. Diriger NZN en tant que PDG/CPO m’a obligé à concilier ces deux vérités simultanément — on ne peut pas surpasser une mauvaise thèse par l’exécution, et on ne peut pas surpasser une mauvaise exécution par la thèse. La création de Polen.me m’a enseigné la leçon la plus coûteuse de toutes : le capital et le temps sont limités, donc chaque fonctionnalité que vous développez est une fonctionnalité que vous n’avez pas développée, et le coût de la poursuite d’une démonstration impressionnante au lieu d’un vrai flux de travail apparaît des mois plus tard, pas sur scène. Au moment où j’ai rejoint Pipefy, la question que je me pose pour chaque fonctionnalité IA est la même que celle que je poserais à propos d’une antenne cellulaire : cette fonctionnalité tient‑elle la route en production, sous une charge réelle, quand personne ne regarde ? Si un agent IA ne fonctionne que dans un environnement de démonstration contrôlé, ce n’est pas un produit — c’est une bande‑annonce.

Vous avez dirigé la formulation et la mise en œuvre de la stratégie IA de Pipefy depuis 2023. Quelles hypothèses concernant l’IA d’entreprise aviez‑vous au départ et qui ont le plus changé avec la maturation de l’IA générative et des agents IA ?

La plus grande hypothèse que j’ai dû abandonner était que le modèle serait le goulot d’étranglement. En 2023, tout le monde — moi y compris — optimisait pour « quel LLM est le plus performant ». Ce qui s’est réellement avéré être le goulot d’étranglement était le contexte : l’agent sait‑il quel est réellement le processus, quelles sont les limites, à quoi ressemble le « terminé » pour la version spécifique du service de comptes fournisseurs du client ? La qualité du modèle continuait de s’améliorer sur une courbe prévisible ; le contexte du processus ne s’améliorait pas de lui-même, car personne ne l’avait structuré. La deuxième hypothèse qui a basculé concernait l’autonomie. Je pensais que le marché voulait des agents qui agissaient totalement indépendamment le plus rapidement possible. Ce que les entreprises veulent réellement — et veulent toujours —, c’est une autonomie bornée : des agents qui prennent de vraies décisions à l’intérieur de règles qu’ils ne peuvent pas enfreindre, avec une traçabilité qui le prouve par la suite. Une autonomie totale sans gouvernance n’est pas de l’ambition, c’est simplement du risque avec une meilleure interface. Le marché a mûri plus rapidement sur les exigences de confiance que sur les exigences de capacité brute, et ce réordonnancement est la plus grande erreur que j’ai commise au départ.

Pipefy fait la distinction entre l’automatisation IA relativement simple et les agents IA capables de raisonner face à des situations ambiguës, de planifier plusieurs étapes et d’exécuter des actions au sein d’un flux de travail. Comment les entreprises devraient‑elles déterminer quand une tâche nécessite réellement un agent IA plutôt que de recourir à une automatisation déterministe, qui reste la meilleure solution ?

Le test que j’utilise est simple : si vous pouvez écrire la règle, écrivez la règle. L’automatisation déterministe reste la bonne solution pour tout ce dont l’arbre de décision est connu à l’avance et ne change pas — acheminer cette facture à cet approbateur si le montant est inférieur à ce seuil. Ce n’est pas une tâche pour un agent, et prétendre le contraire n’ajoute que latence et imprévisibilité à quelque chose qui était déjà résolu. Un agent mérite sa place dès que la situation présente une ambiguïté qu’une règle fixe ne peut résoudre — la facture ne correspond pas exactement au bon de commande, il manque un champ, la demande du client ne correspond à aucune de vos catégories existantes. C’est là que le raisonnement a une réelle valeur : décider de la prochaine action lorsque le « next » n’est pas déjà écrit. L’erreur que je vois les entreprises commettre constamment est de créer un agent pour les 80 % des cas qui étaient déjà déterministes, parce que c’est plus tape-à-l’œil, et de laisser les 20 % ambigus — la partie réellement difficile — à un humain pour les démêler manuellement. Inversez ce ratio et vous avez construit quelque chose de réel.

On observe un glissement croissant des copilotes autonomes vers « l’orchestration agentique », où l’IA peut coordonner des processus s’étendant sur plusieurs systèmes. Qu’est-ce qui distingue une véritable orchestration agentique du simple ajout d’un grand modèle de langage à une plateforme d’automatisation existante ?

Intégrer un nœud LLM dans un flux d’automatisation existant vous donne une étape unique plus intelligente. Une véritable orchestration signifie que l’IA possède une vue persistante et structurée de l’ensemble du processus — pas seulement de cette tâche, mais de sa place dans la séquence, de ce qui s’est déjà produit en amont, de ce qui doit être vrai en aval pour que cela soit considéré comme terminé. La différence réside dans le fait que l’intelligence a une mémoire du processus ou seulement une mémoire de l’invite. Un copilote répond à la question que vous lui posez. L’orchestration coordonne l’action entre des systèmes qui ne communiquent pas nativement — votre ERP, votre CRM, l’API d’un partenaire — tout en héritant des mêmes règles, permissions et piste d’audit que le reste du processus utilise déjà. Si vous devez construire une couche de gouvernance distincte autour de votre fonctionnalité IA parce que la plateforme d’automatisation sous-jacente n’en possède pas, vous n’avez pas d’orchestration agentique — vous avez un chatbot avec accès à l’API, et ce n’est pas du tout le même profil de risque.

Les agents IA sans code permettent potentiellement aux équipes métier d’automatiser des processus de plus en plus complexes sans attendre les ressources d’ingénierie. Comment démocratiser cette capacité sans créer une nouvelle génération d’IA fantôme, d’agents mal conçus ou de risques de sécurité ?

Vous n’obtenez pas une démocratisation sécurisée en demandant aux utilisateurs métier d’être plus prudents — vous l’obtenez en

Faire des garde-fous partie intégrante du revêtement, et non une voie séparée que les gens doivent choisir pour circuler. Chaque agent qu’un utilisateur métier crée hérite des mêmes contrôles d’accès basés sur les rôles, de la même piste d’audit et des mêmes règles métier qui régissent déjà le processus dans lequel il est construit — ce ne sont pas des configurations optionnelles, ce sont des éléments structurels. C’est la véritable réponse à l’IA fantôme : ce n’est pas un problème de politique, c’est un problème d’architecture. L’IA fantôme apparaît lorsque l’outil autorisé est plus difficile à utiliser que celui non autorisé, si bien que les gens créent leur agent dans un compte personnel ChatGPT ou un outil d’automatisation aléatoire sans aucune visibilité pour le service informatique. Si l’expérience sans code est réellement rapide et que la gouvernance est invisible parce qu’elle est automatique, il n’y a aucune raison pour qu’une équipe métier la contourne. Au moment où vous transformez la gouvernance en une étape manuelle que quelqu’un doit se rappeler, vous avez déjà perdu.

À mesure que les agents IA acquièrent la capacité de prendre des décisions et d’exécuter des actions plutôt que de simplement les recommander, comment les organisations doivent-elles déterminer où une autonomie totale est appropriée et où les humains doivent rester dans la boucle ?

L’axe que j’utilise n’est pas « à quel point l’agent est intelligent », mais la réversibilité et le rayon d’impact. Si une mauvaise décision est peu coûteuse à détecter et à annuler — routage, catégorisation, rédaction — laissez l’agent agir et réviser de façon agrégée. Si une mauvaise décision est coûteuse, difficile à inverser, ou touche directement l’argent, la conformité ou la relation client, maintenez un humain dans la boucle pour cette étape précise, même si l’agent a correctement pris les mille dernières décisions. L’erreur consiste à traiter l’autonomie comme un seul réglage que l’on augmente pour l’ensemble du workflow. Les processus réels sont une séquence d’étapes avec des profils de risque très différents, et la bonne conception place l’humain exactement à l’étape où une erreur est coûteuse — pas partout et pas nulle part. C’est aussi pourquoi le modèle humain-dans-la-boucle, bien appliqué, n’est pas une taxe sur la vitesse — c’est la façon dont vous bâtissez la confiance nécessaire pour finalement le supprimer des étapes à faible risque, car vous disposez de preuves montrant quelles décisions l’agent obtient constamment correctement.

Pipefy met l’accent sur la gouvernance grâce à des mécanismes tels que les pistes d’audit, les contrôles d’accès basés sur les rôles, les règles métier et la traçabilité au sein même du workflow. L’intégration de la gouvernance directement dans la couche d’orchestration devient-elle essentielle à mesure que les entreprises font passer les agents IA des expérimentations à la production ?

Ce n’est pas en train de devenir essentiel — c’est déjà le cas, et les entreprises qui le découvrent à leurs dépens sont celles qui ont d’abord mis des agents en production et qui construisent maintenant la piste d’audit a posteriori. C’est à l’envers, et c’est coûteux à corriger rétroactivement. Si les pistes d’audit, le contrôle d’accès basé sur les rôles et la traçabilité ne sont pas natifs à la couche d’orchestration elle‑même, chaque nouvel agent que vous déployez devient un nouveau point où la gouvernance peut échouer discrètement — et vous ne le découvrirez que lorsqu’un auditeur, un régulateur ou un incident posera la question. Intégrer la gouvernance dans la couche d’orchestration signifie que chaque action d’un agent hérite automatiquement des mêmes règles et laisse les mêmes preuves qu’une action humaine, sans que quiconque ait à se souvenir de la configurer séparément. Les entreprises qui passent des expériences d’IA à l’IA en production découvrent que les critères de succès d’un pilote et ceux d’une production diffèrent : un pilote doit fonctionner, la production doit être défendable. La gouvernance est la différence entre ces deux seuils.

De nombreuses entreprises peuvent démontrer un pilote IA impressionnant mais peinent à le traduire en valeur commerciale mesurable. Sur quels indicateurs les dirigeants doivent-ils se concentrer pour déterminer si une initiative d’automatisation IA délivre réellement un ROI, et quelles sont les raisons les plus courantes pour lesquelles les pilotes prometteurs échouent à être mis à l’échelle ?

Je me méfie de toute discussion sur le ROI de l’IA qui commence par « heures économisées », car qui a économisé ces heures, et comment le vérifier ? Les indicateurs qui résistent réellement à l’examen du CFO sont ceux que les auditeurs peuvent confirmer de façon indépendante : le temps de cycle d’un processus spécifique, avant et après ; le taux d’erreur ou de retouche ; le pourcentage d’un flux de travail qui se termine désormais sans intervention humaine ; et la couverture de la traçabilité des audits — pouvez‑vous montrer, pour chaque décision agentique, pourquoi elle a été prise. Si vous ne pouvez pas produire cette piste, vous n’avez pas de chiffre de ROI, vous avez une anecdote. Les pilotes échouent à se déployer à grande échelle presque toujours pour la même raison : ils ont été conçus pour prouver que le modèle fonctionne, pas pour prouver que le processus fonctionne de bout en bout, en production, intégré aux systèmes dont le reste de l’entreprise dépend déjà. Un pilote qui vit dans un bac à sable, déconnecté du véritable système de référence, semblera toujours meilleur qu’il ne le sera une fois connecté à tout le reste déjà en marche. L’échelle est un problème d’intégration de systèmes revêtu d’un costume d’IA.

Vous avez également dirigé des initiatives de changement organisationnel chez Pipefy tout en introduisant de nouvelles capacités d’IA. D’après votre expérience, quelle part de l’adoption réussie de l’IA en entreprise est réellement un défi technologique versus un défi de processus, de culture et de gestion du changement ?

Pour être honnête, l’adoption réussie de l’IA en entreprise se compose à 20 % de technologie et à 80 % de tout le reste. La technologie fonctionne majoritairement aujourd’hui — ce n’est pas là que je perds le sommeil. Ce qui détermine réellement si une initiative IA s’enracine, c’est que les personnes dont le travail change fassent suffisamment confiance au système pour abandonner la vérification manuelle qu’elles effectuaient depuis dix ans, et que la direction soit prête à redessiner le processus plutôt que de simplement coller l’IA sur l’ancien. Nous avons traversé cela en interne en construisant nos propres outils d’ingénierie — la technologie pour automatiser certaines parties de notre construction logicielle existait bien avant que l’équipe ne lui accorde suffisamment de confiance pour arrêter de tout revérifier à la main. Le déclic n’a pas été un meilleur modèle, mais une preuve visible, répétée assez de fois, que le jugement du système correspondait au leur. La gestion du changement pour l’IA n’est pas un exercice de communication, c’est un exercice d’accumulation de preuves — vous gagnez la confiance par de petits lots vérifiables, vous ne l’annoncez pas lors d’une assemblée générale.

En regardant vers l’avenir, pensez‑vous que les logiciels traditionnels de flux de travail et de processus métier évolueront vers des couches d’orchestration où humains, agents IA et systèmes d’entreprise collaborent en continu ? Le cas échéant, qu’est‑ce qui changera fondamentalement la façon dont les entreprises conçoivent et gèrent leurs opérations ?

Oui, et je pense que le virage est plus important que ce que la plupart des gens anticipent. Le logiciel de flux de travail servait autrefois à documenter comment le travail devait se dérouler. Il devient l’endroit où le travail se déroule réellement — un environnement d’exécution en direct où humains, agents et systèmes d’entreprise agissent tous au sein du même processus gouverné simultanément, au lieu qu’un humain utilise le logiciel comme un archiviste passif après coup. Ce qui change fondamentalement, c’est l’endroit où le « système de référence » réside réellement. Le registre était autrefois une base de données mise à jour une fois que quelque chose s’était déjà produit en dehors. Dans une couche d’orchestration, le registre et l’exécution sont la même chose — le processus devient l’interface, accessible non seulement via un écran mais aussi via une API, un serveur MCP, une CLI, de sorte que tout agent, interne ou celui d’un partenaire, puisse agir à l’intérieur sous les mêmes règles qu’un humain. Les entreprises qui considèrent ce virage comme « ajouter l’IA à mes outils existants » continueront de se heurter au plafond que j’ai décrit précédemment. Celles qui traitent leur couche de processus comme le produit réel — ce qui vaut la peine d’investir pour la structurer correctement — seront celles qui multiplieront un avantage que personne ne pourra copier simplement en achetant le même modèle d’IA.

Merci pour cette excellente interview, les lecteurs qui souhaitent en savoir plus devraient visiter Pipefy.