
PEGAInnovate Paris 2026 : promesses de l'IA et terrain
PEGAInnovate Paris 2026 : Blueprint, IA agentique et retours de Groupama, AWS, BPCE Assurances et Capgemini, lus par Adrien PIQUENET SOLHEID, Lead System Architect Pega.
Adrien PIQUENET SOLHEID
10/3/20269 min read
Le 24 septembre, Pega réunissait clients et partenaires au 28 George V pour son événement régional parisien. Au programme : la vision produit de Kerim Akgonul, puis les retours de Groupama, AWS, BPCE Assurances et Capgemini. J'ai passé l'après-midi à confronter ce qui était annoncé à ce que je vois sur les projets depuis bientôt dix ans. Voici ce que j'en retiens, intervention par intervention, et ce que j'en conclus pour ceux qui doivent décider.
Le 24 septembre, Pega organisait PEGAInnovate à Paris : une keynote produit, quatre retours de clients et partenaires, puis des démonstrations. Le fil conducteur affiché était l'IA agentique. Dans les faits, les interventions ont surtout parlé d'organisation, de gouvernance et de méthode, et c'est ce qui en a fait l'intérêt.
J'y suis allé avec une question en tête : qu'est-ce qui, dans ce qui est présenté, changera vraiment la façon dont on conçoit et fait tourner une application Pega chez un grand compte ? Je travaille sur Pega depuis 2017. Quand une démonstration montre une application construite en quelques minutes, je pense à ce qui se passera six mois plus tard, avec des milliers de cas en cours et une évolution réglementaire à intégrer en urgence.
Un après-midi au 28 George V


Kerim Akgonul a ouvert la séance en posant la question qui devrait lancer toute discussion sur le sujet : pourquoi l'IA ? Sa réponse tenait en trois bénéfices. Des résultats plus rapides, de meilleures décisions, moins d'effort. Ces objectifs n'ont rien de propre à Pega. Ce qui m'a intéressé, c'est leur répartition sur le cycle de vie d'une application : concevoir, construire, exécuter.
Dernier temps, l'exécution : des agents IA intégrés aux workflows, capables de traiter une partie du travail de manière autonome dans un cadre prévisible. L'approche me paraît juste parce que l'agent s'insère dans un cas Pega déjà structuré, avec ses étapes, ses règles, ses droits d'accès et son historique. Son action reste tracée comme celle d'un utilisateur.
Reste à savoir comment on mesure sa fiabilité et comment on reprend la main quand il se trompe. Sur un processus réglementé, où chaque validation doit être conforme et traçable, ce sont les premières questions que je poserais.
Concevoir avec Blueprint
Construire avec Infinity Studio
Blueprint permet de décrire un processus métier en langage naturel, en français compris, et d'en obtenir une modélisation lisible par le métier et conforme aux standards de la plateforme.
La démonstration est partie quasiment de zéro pour aboutir à un Blueprint fonctionnel. La démo était sans doute un peu préparée, mais le résultat restait parlant : un vrai cas de service client téléphonique, déroulé de bout en bout depuis Blueprint. Le présentateur a appelé l'application en direct, et elle lui a répondu en temps réel. Petit moment de rire dans la salle quand il lui a demandé de traduire sa réponse en français : l'IA s'est exécutée, avec un accent américain.
Le gain est réel. Aligner métier et IT sur une application Pega demandait autrefois des semaines d'ateliers, de spécifications et de maquettes, avec un premier sprint qui ne ressemblait plus toujours à ce que le métier avait en tête. Avec Blueprint, un premier modèle existe dès la première réunion. Il ne règle en revanche ni les arbitrages métier, ni l'intégration au SI existant, ni la volumétrie. L'outil déplace l'effort de la formalisation vers la décision, ce qui suppose une organisation capable de décider plus vite. Si chaque arbitrage passe encore par trois comités, le temps gagné en modélisation sera perdu en attente.
Pour la construction, Pega met en avant Infinity Studio et son assistant IA. Annoncé avec Infinity '26, le plan d'implémentation est généré automatiquement à partir du Blueprint : il découpe le travail en tâches que l'assistant peut ensuite réaliser. C'est précisément l'endroit où les projets dérivent le plus.
J'attends toutefois de voir l'outil en conditions réelles : une application qui traite plusieurs dizaines de milliers de cas par jour se construit aussi sur la structure des données, les traitements en arrière-plan, la sécurité et la réutilisation. Un assistant qui accélère la production de règles est utile. S'il produit des règles que personne ne comprend, c'est de la dette technique à retardement.
Exécuter avec les workflows agentiques
La vision présentée par Pega
Kerim Akgonul, Chief Product Officer, Pega
Halim Yahia a expliqué pourquoi Groupama a retenu Pega, et tous ses arguments portaient sur l'architecture et l'organisation. Une plateforme capable de porter un parcours unifié, du marketing jusqu'à l'après-vente, ce qui supprime une partie des ruptures entre outils. La modularité et la facilité d'intégration, indispensables pour un groupe qui construit par morceaux autour d'un SI existant. Le cloud, une première pour Groupama, avec tout ce que cela implique en sécurité et en exploitation.
Le point le plus intéressant pour un décideur reste le CoE mis en place dès le démarrage, avec deux objectifs : la qualité et une base de réutilisation. Le centre d'excellence arrive souvent tard, quand la deuxième application révèle des composants non réutilisables et des conventions divergentes. Il passe alors une partie de son temps à corriger l'existant. Créé dès le départ, il pose les règles communes avant la première ligne de code, et chaque application profite de la précédente.
Le CoE sert aussi la montée en compétences. J'ai accompagné une dizaine de personnes jusqu'à la certification System Architect, et le constat est toujours le même : une équipe qui partage des pratiques communes produit un code plus homogène et gagne en autonomie plus vite. Avant de choisir quelle IA mettre dans ses processus, il faut une plateforme structurée pour tenir dans le temps, faute de quoi l'IA amplifiera ses défauts.
Groupama et le choix d'une plateforme
Halim Yahia, directeur de projet transformation, Groupama
Pablo Martinez a listé trois freins au déploiement de l'IA : une gouvernance à réorganiser, souvent avec des instances propres à l'IA, la confiance, et le cadre réglementaire, qui pèse sur la banque et l'assurance. Il a proposé trois leviers : la clarté, la responsabilité et la curiosité.
Son idée la plus forte portait sur le moment de la gouvernance. Elle intervient le plus souvent au lancement du projet ou à l'audit. AWS défend une gouvernance intégrée au runtime, avec des contrôles et une supervision qui font partie de l'application en production. Pega s'y prête naturellement : chaque cas garde son historique, les règles sont versionnées, et l'on sait quelle logique s'appliquait à un instant donné. La traçabilité est une propriété qui se conçoit avec le processus, et qui coûte nettement plus cher à ajouter une fois l'application en production.
Le conseil pratique d'AWS tient en deux critères : commencer par de petits cas d'usage avec un retour sur investissement clair, et choisir des usages réversibles. Le ROI oblige à définir ce qu'on mesure avant de commencer. La réversibilité permet de prendre des risques sans déstabiliser l'organisation. Un MVP, puis des itérations : c'est ainsi que les projets Pega réussis avancent depuis longtemps, et je ne vois aucune raison d'aborder l'IA autrement.
AWS et la gouvernance du risque IA
Pablo Martinez, spécialiste conformité services financiers EMEA, AWS
BPCE Assurances utilise Pega Customer Decision Hub pour proposer au conseiller la meilleure action au bon moment de l'échange. Nathalie Barthaux a d'abord insisté sur l'organisation : métier, marketing, IT, data, CoE Pega et équipes offre autour de la même table. C'est la partie la moins spectaculaire de l'intervention, et celle que je retiendrais en premier. Un moteur de décision dépend de données fiables, d'un catalogue à jour, de règles d'éligibilité claires et d'un retour terrain, qui appartiennent chacun à une équipe différente.
J'ai commencé ma carrière dans la donnée, et j'y ai appris qu'un indicateur légèrement faux fait perdre la confiance des utilisateurs bien plus vite qu'elle ne se gagne. Un score de recommandation suit la même règle : après deux ou trois propositions incohérentes, le conseiller cesse de le regarder.
Les gains présentés vont dans ce sens, en vente croisée comme en vente additionnelle. Sans outil, un conseiller propose surtout les produits qu'il connaît le mieux, parce qu'il est plus à l'aise pour les vendre et que personne ne maîtrise l'ensemble d'un catalogue aussi large. Avec Customer Decision Hub, la proposition repose sur un score calculé à partir du contexte du client, ce qui la rend potentiellement plus pertinente.
Quand le produit recommandé est un produit que le conseiller connaît mal, l'outil lui suggère une phrase d'accroche pour le présenter. Il n'hésite plus au moment d'introduire l'offre, et si le client est intéressé, il retrouve le détail du produit pour répondre précisément à ses questions. Le conseiller peut ainsi se concentrer sur le besoin du client : l'IA prend en charge la recherche et laisse à l'humain la partie qui demande du jugement.
BPCE Assurances a aussi présenté un résultat concret sur l'assurance auto. Avant Customer Decision Hub, les conseillers n'avaient pas le réflexe de proposer ce type de contrat. Désormais, l'outil le leur suggère sur une large part des appels, et une partie de ces propositions aboutit à une souscription. C'est un canal de vente qui n'existait pas auparavant, et un gain directement attribuable à l'outil.
BPCE Assurances et la décision en temps réel
Nathalie Barthaux, cheffe de projet expérience client, BPCE Assurances
Franck Meunier a présenté le programme Maestro, consacré aux traitements de back-office de LCL, ainsi que la méthode CAALM (Capgemini AI Assisted Legacy Modernization), qui consiste à avancer sous contrainte de temps pour aboutir au décommissionnement des applications historiques.
Cette contrainte de temps est à mon sens la vraie force de l'approche. Sans date de fin, l'ancien et le nouveau système cohabitent pendant des années, et l'on paie deux fois. Une date de décommissionnement oblige à prioriser et à trancher. Sur les remplacements d'outils historiques que j'ai menés, il fallait toujours comprendre ce que faisait réellement l'existant, y compris les règles appliquées par habitude sans être écrites nulle part. L'IA peut accélérer cette analyse. Le choix de ce qu'on garde, simplifie ou abandonne reste humain.
Capgemini a aussi insisté sur la conduite du changement dès le cadrage, et je partage cette conviction. Traitée en fin de projet, elle arrive quand les choix qui conditionnent l'adoption sont déjà faits. Avec Blueprint, on peut montrer aux utilisateurs leur futur outil dès les premières semaines, quand il est encore temps d'en tenir compte.
Capgemini et la modernisation du legacy
Franck Meunier, VP Group Account Executive, Capgemini
La troisième : il faut continuer à expérimenter. Choisir un processus connu dont les irritants sont identifiés, associer métier et IT dès le départ, définir un ou deux indicateurs, s'appuyer sur Blueprint pour montrer vite quelque chose, et prévoir comment revenir en arrière. Ces étapes sont classiques, et ce sont elles que j'ai retrouvées chez tous les clients qui avaient des résultats à présenter.
Ce que j'en retiens
Les outils IA accélèrent la conception. Faire tenir une application en production reste un travail d'architecture.
Dans les quatre retours d'expérience, l'IA arrive après un objectif métier déjà défini : une plateforme et un CoE chez Groupama, l'aide au conseiller chez BPCE Assurances, des cas d'usage mesurables chez AWS, une date de décommissionnement chez Capgemini. J'en tire trois convictions.
La première fait écho à ce qu'a raconté Karim Zein, VP et Managing Director EMEA South & MEA chez Pega, en clôture de l'après-midi. Il rencontre régulièrement des dirigeants et des comités exécutifs, et tous lui tiennent le même discours : il faut faire de l'IA, mais comment s'y prendre ? Que la direction porte le sujet est une bonne chose, ce type de projet a besoin de sponsors.
Une démarche IA uniquement descendante reste pourtant une erreur à mes yeux. Un objectif du type « tant de processus augmentés par l'IA d'ici deux ans » pousse les équipes à chercher des cas d'usage pour atteindre le chiffre, plutôt qu'à partir de leurs problèmes réels.
Une partie des meilleures idées vient des équipes opérationnelles, celles qui utilisent les outils au quotidien et qui sont parfois les vrais moteurs du changement. Les écouter vaut la peine, et Pega permet justement d'accélérer fortement la mise en œuvre de leurs idées. La direction donne le cadre, les moyens et la gouvernance. Le choix des usages gagne à venir du terrain.
La deuxième : il faut se méfier des promesses, vibe coding en tête. J'ai écrit que l'assistant de Blueprint pouvait faire gagner des semaines en cadrage, et je le pense toujours. Une application de grand compte doit pourtant s'intégrer au SI, tenir la charge, respecter la sécurité et la conformité, et rester maintenable par d'autres équipes. Aucun de ces sujets ne se règle en décrivant un processus en langage naturel. Réduire le nombre d'architectes parce que l'outil génère du code serait un mauvais calcul : c'est leur relecture qui évite que la vitesse gagnée devienne de la dette.
Je m'appelle Adrien, je suis Pega LSA certifié. Je conçois et modernise des applications complexes et à fort trafic, avec la conviction qu'une bonne application se construit autant qu'elle se transmet.

