Éditeur français d’une plateforme de Business Process Automation open source déployée depuis 2009 chez de grands comptes régulés, Bonitasoft est devenue Ofelia en 2026 et a lancé Ofelia Agentic : une offre SaaS dont l’interface conversationnelle est l’expérience principale, adossée au moteur d’exécution déterministe du produit historique. Ce type de trajectoire, où une couche IA vient enrichir un socle éprouvé sans le remettre en cause, relève de ce que nous appelons chez SoftFluent, la modernisation applicative augmentée par l’IA.

Nicolas Chabanoles, CPTO, revient sur la façon dont l’IA a été intégrée au produit et aux pratiques des équipes, sans céder sur la traçabilité qu’exigent la banque et l’assurance.

Qui est Nicolas Chabanoles, CPTO d’Ofelia ?

Nicolas Chabanoles dirige la stratégie produit et la technologie chez Ofelia, avec la R&D et le Product Management sous sa responsabilité. Ingénieur logiciel de formation, il pilote le lancement d’Ofelia Agentic et la transformation des pratiques d’ingénierie qui l’accompagne.

Une architecture hybride, choix tactique

Qu’est-ce qui vous a poussé à intégrer l’IA sans attendre que le marché arrive à maturité ? 

« Deux raisons. La première tient à ce que le marché nous disait, et il nous disait deux choses opposées. ChatGPT avait prouvé que l’expérience conversationnelle pouvait être adoptée très vite, y compris par des profils non techniques : il y avait là une UX capable d’abaisser fortement la barrière à l’entrée sur un produit comme le nôtre, historiquement réservé aux services IT. Mais ce même marché n’était pas prêt à confier à l’IA la responsabilité de décider et d’agir en autonomie dans ses processus, ce que le terme agentique promet pourtant.

La seconde, c’est que cet écart était exactement à la forme de ce que nous avions déjà. Un moteur d’exécution déterministe éprouvé chez des banques et des assurances, sur lequel poser une couche conversationnelle sans rien remettre en cause de ce qui garantit la traçabilité chez nos clients. Là où un nouvel entrant devait choisir entre les deux, nous pouvions offrir les deux.

D’où l’architecture hybride : l’IA conversationnelle sert l’UX, les décisions prises dans les procédures internes restent gérées par le moteur déterministe du produit historique, et la part d’autonomie laissée aux agents peut augmenter sans refonte. Cette limite du marché était notre point de départ, pas notre horizon : nous savions qu’elle bougerait.

Notre rôle n’est pas d’être disruptif pour nos clients, c’est d’être leur support d’adoption. Nous n’anticipons pas la maturité du marché, nous anticipons la technologie : l’architecture est prête à donner plus d’autonomie aux agents, et nous ouvrons ce curseur au rythme où un client régulé peut l’auditer. Pas au rythme du discours ambiant. »

Trois places pour l’IA, trois types de gains

Quels indicateurs avez-vous vu bouger ?

« L’IA occupe trois places différentes chez nous, avec une seule règle : elle propose, le moteur déterministe exécute et trace.

En interne, elle outille le support et le customer success : temps de réponses raccourcis, meilleure qualité de réponse, progression du NPS annuel. Dans le produit historique, ce sont nos clients qui l’appellent depuis leurs propres processus, via des connecteurs, pour traiter de la donnée ou éclairer une décision. L’enchaînement des étapes, les contrôles et la piste d’audit, eux, restent déterministes. Sur Ofelia Agentic, l’interface conversationnelle devient l’UX principale : nos premiers utilisateurs sont opérationnels en moins d’une heure.

Côté produit, nous avons divisé par deux notre délai moyen de correction des bugs et des vulnérabilités. Le paradoxe, c’est que l’IA nous permet aussi d’en détecter davantage, et plus en amont : nous en trouvons plus, et nous les corrigeons deux fois plus vite. Pour un éditeur qui vend à des secteurs régulés, c’est le bon sens de la courbe.

Enfin, sur le nouveau produit, nous sommes passés du concept à un produit commercialisable en un an. Sans l’adoption de l’IA dans nos pratiques de développement, il nous aurait fallu plus de temps, avec une équipe deux fois plus grande. »

Embarquer les équipes : commencer par plusieurs bouts à la fois

Et sur la partie interne, comment avez-vous embarqué les équipes ? 

« Honnêtement, au début, on ne savait pas par quel bout le prendre. J’ai vu toutes les réactions possibles dans les équipes : de la réticence, de l’enthousiasme, de l’indifférence. C’est humain et plutôt sain face à une nouveauté technologique. Il vaut mieux un premier regard critique qu’une adhésion aveugle à la tendance brillante.

Faute de savoir quelle était la bonne première étape, nous avons choisi d’attaquer par plusieurs bouts à la fois.

Concrètement, nous avons :

• Engagé un programme d’acculturation avec Bpifrance, qui proposait un audit et un accompagnement pour identifier des cas d’usage département par département ;
• Lancé des créneaux internes que nous appelons « show and tell », pendant lesquels les développeurs qui expérimentaient sur des projets personnels venaient montrer ce qu’ils faisaient, ce qui marchait, ce qui ne marchait pas ;
• Rendu obligatoire un socle de formation commun, construit sur les formations gratuites d’Anthropic, et ouvert un budget pour les formations spécialisées par métier, par exemple sur l’usage de l’IA dans la pratique du Product Management ;
• Mis à disposition des licences professionnelles ChatGPT, Claude et Gemini, ainsi que des outils de développement assistés par IA comme Claude Code, avec un rythme d’expérimentation quasi mensuel, dans un cadre défini en amont avec l’IT : offres professionnelles sans réutilisation des données pour l’entraînement, liste d’outils validés, règles explicites sur ce qui ne sort pas de l’entreprise (code client, données personnelles, données de production) ;
• Monté une équipe dédiée au nouveau produit.

La règle était simple : essayer, comparer, partager, dans le cadre posé. Sur la R&D, j’ai vu une vraie progression, depuis les premiers usages de ChatGPT (« un Google amélioré ») jusqu’à Claude Code, GitHub Copilot, Codex, Manus, Lovable, Bolt et bien d’autres. Le fait d’en essayer beaucoup et de voir à chaque fois une progression positive a fait grandir la confiance dans les équipes par l’expérimentation elle-même. »

Le rôle central des RH

Vous n’avez pas imposé l’usage de l’IA. Comment cela a-t-il pu se diffuser aussi largement ? 

« Nous n’avons fixé aucun objectif chiffré d’usage par salarié. L’obligation portait sur la formation, pas sur l’usage. Nous avons démarré début 2025, aujourd’hui, toutes les équipes utilisent de l’IA, à des degrés variables, et toutes partagent ce qu’elles font. 

Notre DRH a joué un rôle très important. Elle a pris le leadership de l’animation interne : les « Show and Tell », l’identification des formations pertinentes, la valorisation des certifications dans le SIRH. Elle a travaillé main dans la main avec l’équipe IT, qui tenait le cadre de sécurité et de conformité RGPD. 

La réussite tient aux relais à chaque niveau : une direction cohérente, des managers qui identifient les frictions et dégagent du temps pour expérimenter, des RH qui portent le message que ces compétences deviennent indispensables pour rester employable demain. »

Product Manger, Product Engineer : les rôles évoluent

En quoi l’IA a-t-elle changé le quotidien de vos équipes ? 

« Elle a rebattu les rôles, en particulier la frontière entre Product Manager et développeur. 

Les outils IA nous challengent énormément sur le besoin fonctionnel : qu’est-ce que tu cherches vraiment à construire ? Une fois que c’est clair, ils sont capables de générer le code correspondant. La personne qui construisait à la main auparavant se concentre de plus en plus sur la partie produit : quelle expérience, pour qui, pour quoi ? 

Nous sommes en train de faire monter nos ingénieurs du statut de développeur à celui de Product Engineer, avec la responsabilité de définir le produit et de livrer en production. En parallèle, le rôle de Product Manager glisse davantage vers la partie Discovery : parler avec les utilisateurs, les clients, les partenaires, comprendre où sont les vraies difficultés à résoudre.

Ce qui me plaît dans cette évolution, c’est que je vais pouvoir profiter de tous les cerveaux de mes ingénieurs pour la créativité, plutôt que de dépendre d’une seule personne censée avoir la réponse à tout. »

Le nouveau centre de coût, c’est décider ce qu’on ne construit pas

Cela change-t-il la gouvernance produit ? 

« C’est même le premier sujet que nous avons dû revoir. À l’ère de l’IA, qui décide de quoi ? Qu’est-ce qui reste une décision importante et qu’est-ce qui n’en est plus une ? 

Avant, produire du code était long et coûteux, il fallait donc être sûr d’avoir pris la bonne décision avant de lancer un développement. Aujourd’hui, le code devient une commodité : le coût de se tromper baisse. On devrait donc tester davantage, mettre les choses face aux utilisateurs plus vite, et garder uniquement ce qui marche. 

Le nouveau point le plus coûteux dans la chaîne, c’est de trier les idées. Si je suis capable de tout construire, la vraie question devient : qu’est-ce qu’il ne faut pas construire ? Le champ des possibles est infini, mais un produit reste cohérent, lisible, proportionné. Sinon, on se retrouve à faire des chaussettes, du café et de l’automatisation de processus, ce qui n’est pas très judicieux. »

Une chaîne de développement automatisée, sous contrôle

Vous parliez d’agents IA qui prennent en charge une partie du cycle de développement. Où en êtes-vous concrètement ? 

« Le périmètre est précis : un module de notre offre destiné aux profils les moins techniques, sur l’outillage de développement. Il ne touche pas à l’exécution des processus en production chez nos clients, qui reste sur le moteur déterministe. 

Sur ce périmètre, une demande d’évolution validée par l’équipe produit est prise en charge par un agent qui rédige une première spec, un deuxième agent produit le code, un troisième vérifie que le code répond à la spec. Chaque décision d’agent est journalisée et rejouable. La chaîne CI/CD est bloquante : tests automatiques, contrôle de qualité du code, garde-fous architecturaux, scans de cybersécurité. Un ingénieur valide en fin de chaîne avant la mise en production.

C’est notre manière de garder un « human in the loop », mais placé là où il apporte le plus : pas pour relire ligne à ligne ce que la chaîne vérifie déjà mieux que lui, pour décider si ce qui a été produit doit partir en production. »

Note : Le récit de Nicolas illustre bien pourquoi, chez SoftFluent, nous démarrons souvent nos missions par un audit applicatif : avant de projeter une couche IA ou une chaîne agentique sur un produit existant, il faut connaître précisément l’état du socle qu’on cherche à préserver.

Le budget IA vu comme un budget RH

Comment adressez-vous la question du ROI, qui revient en boucle dans le débat public ? 

« C’est une question de proportion. Mettre des millions d’un coup partout dans l’entreprise sans regarder les bénéfices, c’est probablement de l’argent jeté par les fenêtres. Mais à l’inverse, attendre un ROI garanti à 100 % avant de bouger, c’est se priver de l’opportunité de le découvrir par l’expérimentation.

Je partage volontiers une approche que je trouve assez maligne : quand une activité nécessite un recrutement supplémentaire, plutôt que de recruter tout de suite, on décale de trois mois et on utilise un budget équivalent au salaire pour expérimenter avec l’IA. À la fin du trimestre, on voit ce qu’on a réussi à couvrir. Deux issues possibles : soit le besoin de recrutement diminue, soit il change de nature (un profil plus junior peut suffire pour la partie qui reste).

Chez nous, cela s’est traduit concrètement : un recrutement de développeur a été gelé. L’équipe en place et la chaîne agentique déployée sur ce module ont absorbé le besoin.

Cela revient à traiter le budget IA comme un budget de ressources humaines, dans une logique d’investissement, plutôt que comme un budget IT sur lequel on serait en permanence sur la défensive. »

Organiser la veille sans se noyer

Comment gérez-vous la veille sur un sujet qui bouge aussi vite ?

« Nous utilisons des channels Slack dédiés. Celui qui trouve quelque chose le partage avec sa propre lecture : ce que ça évoque, pourquoi c’est intéressant, pour qui dans l’entreprise. Sans cette prise de recul, nous serions noyés. Personne ne lit tout, mais chacun sait qui a documenté quoi. Ce n’est pas magique, ça fonctionne.

Commencer, puis corriger la trajectoire

Quel conseil donneriez-vous à un CTO qui hésite encore à franchir le pas ?

« Le premier conseil est très générique, il vaut pour à peu près n’importe quelle décision : quand on ne sait pas par où commencer, il faut commencer. Rester dans l’immobilisme parce qu’on n’a pas identifié la bonne première étape, c’est déjà s’être trompé. On corrige la trajectoire en cours de route.

Le second est plus concret. Le cas d’usage que je vois le plus souvent porter ses fruits, c’est de faire parler sa base de connaissances interne via un agent conversationnel. La donnée est presque toujours mal accessible et éclatée en silos dans les entreprises, et il y a rarement besoin d’attendre un grand projet de nettoyage préalable. On connecte les sources, on pose des questions, on regarde les réponses. C’est déjà un très bon point de départ pour tirer de la valeur rapidement. »

Nicolas Chabanoles ne présente pas cette démarche comme un modèle, mais il ne cache pas son intérêt pour la suite. « Ce qui me motive, c’est ce que nous allons pouvoir construire avec ça. Nous livrons aujourd’hui des choses qui n’auraient pas été finançables il y a deux ans, sur des sujets où nos clients attendaient depuis longtemps. C’est le début, et c’est ce qui rend la période intéressante. »