Migration Camunda 7 vers 8 : qui paie quand le moteur Zeebe trahit vos processus ?

La confusion la plus dangereuse, dans un projet de migration, naît d'un malentendu sémantique : le client croit acheter une montée de version, vous savez livrer un changement de moteur d'exécution. Camunda 7 repose sur un moteur de processus embarqué dans une JVM, adossé à une base de données relationnelle qui sert de source de vérité transactionnelle. Camunda 8 repose sur Zeebe, un moteur distribué, event-sourced, qui ne partage ni le même modèle de persistance, ni la même garantie transactionnelle, ni la même façon d'exécuter les job workers.

Concrètement, des notions que vous teniez pour acquises en Camunda 7 disparaissent ou se transforment : la transaction qui englobait plusieurs activités synchrones, l'exécution optimiste avec rollback sur la base, l'accès direct à l'API Java du moteur depuis un delegate. En Camunda 8, l'exécution est asynchrone par nature, les workers récupèrent des jobs par polling ou streaming, et la frontière transactionnelle se réduit à l'unité d'exécution du moteur. Un processus qui fonctionnait parfaitement en 7 peut, transposé tel quel, produire des comportements subtilement différents en 8.

Ce décalage est précisément ce qui transforme une migration en zone de risque professionnel. Vous ne réécrivez pas du code : vous redéfinissez le comportement attendu d'un système qui orchestre, souvent, des paiements, des souscriptions ou des commandes.

Cette différence de nature a une conséquence directe sur l'estimation de la charge. Un client qui raisonne en termes de montée de version s'attend à un coût marginal et à une bascule rapide. Vous, qui savez qu'il s'agit d'un changement de moteur, savez que l'effort réel inclut la réécriture du code d'intégration, la reconception des frontières transactionnelles, une phase de tests dédiée et une stratégie de coexistence des instances. Si cet écart d'estimation n'est pas explicité dès le cadrage, il devient le terreau d'un futur litige : le client reprochera un dépassement de budget ou de délai, sans percevoir qu'il avait commandé un chantier qu'il croyait être une simple mise à jour.

Certaines régressions de migration reviennent avec une régularité frappante dans les missions Camunda. Les connaître, c'est déjà commencer à se protéger.

La frontière transactionnelle qui disparaît

En Camunda 7, plusieurs activités synchrones pouvaient partager une même transaction de base de données : soit tout passait, soit tout était annulé. En Camunda 8, cette garantie n'existe plus de la même manière. Si votre modèle 7 s'appuyait implicitement sur cette atomicité pour, par exemple, débiter un compte et créer une commande dans le même bloc, la transposition naïve en 8 peut laisser le débit effectué sans la commande associée.

Les variables et l'historique qui ne migrent pas tels quels

Il n'existe pas de bouton magique pour transférer les instances en cours d'exécution de 7 vers 8. Les stratégies réelles passent par une coexistence temporaire : on laisse les instances 7 se terminer sur l'ancien moteur, on démarre les nouvelles instances sur le moteur 8. Si ce point n'a pas été tranché et documenté, le client peut découvrir des milliers d'instances bloquées et vous en imputer la responsabilité.

Les incidents et le retry repensés

La gestion des incidents, des temporisations et des stratégies de retry diffère. Un worker qui ne configure pas correctement son nombre de tentatives ou son timeout peut faire reprendre un job déjà traité, donc rejouer une action métier sensible. C'est exactement le type d'effet de bord qui débouche sur un litige en responsabilité civile professionnelle.

Le code de glue qui ne se transpose pas

En Camunda 7, il était courant d'écrire des delegates Java qui accédaient directement à l'API du moteur, lisaient et modifiaient des variables dans le même contexte d'exécution, voire pilotaient le déroulement de l'instance depuis le code. En Camunda 8, ce couplage fort disparaît : l'interaction passe par des job workers découplés qui communiquent avec le moteur via un protocole externe. Tout le code de glue bâti sur l'API embarquée doit être repensé, pas seulement recompilé. Un client qui découvre que ce travail de réécriture n'avait pas été chiffré dans la mission y verra, à tort ou à raison, une sous-estimation de votre part — d'où l'importance d'un périmètre explicite.

Dans une migration, la chaîne de responsabilité est trouble. L'éditeur fournit l'outil, l'intégrateur ou l'ESN pilote le projet, le client exploite. Mais c'est vous, consultant Camunda, qui posez les choix de modélisation et d'architecture d'exécution. Quand une régression survient en production, le réflexe du client est de remonter à la personne qui a pris la décision technique.

Juridiquement, votre responsabilité s'analyse au regard d'une obligation de moyens : on attend de vous une diligence conforme à l'état de l'art, pas un résultat garanti à 100 %. Mais cette nuance protectrice s'effondre si aucun document ne trace vos préconisations, vos réserves et le périmètre exact de votre mission. Un consultant qui a écrit, en amont, que la stratégie de coexistence relevait du client, ou que tel processus critique nécessitait une phase de tests de charge dédiée, se trouve dans une position défendable. Celui qui n'a rien écrit affronte la réclamation à mains nues.

La meilleure assurance technique d'une migration Camunda, c'est la traçabilité écrite de vos décisions et de vos réserves. La meilleure assurance financière, c'est la RC Pro qui prend le relais quand la traçabilité ne suffit pas.

Avant d'ouvrir le modeleur, plusieurs réflexes réduisent radicalement votre exposition.

• Définir le périmètre par écrit : précisez si vous concevez seulement les processus, si vous opérez la plateforme, et qui décide de la stratégie de migration des instances en cours.
• Identifier les processus critiques : tout ce qui touche au paiement, à la souscription ou à un SLA contractuel mérite une attention et des tests renforcés, documentés comme tels.
• Prévoir une phase de coexistence : ne jamais promettre un basculement instantané d'un parc d'instances actif.
• Tester les compensations et les retries avant la bascule, et conserver les preuves de ces tests.

Si vous opérez vous-même la plateforme du client, votre exposition grimpe d'un cran : vous ne répondez plus seulement de la conception, mais aussi de l'exploitation. Pensez aussi à la dimension matérielle de votre activité : si vous hébergez ou administrez des environnements, une couverture du matériel informatique complète utilement la responsabilité civile.

Une migration Camunda 7 vers 8 réussie est invisible. Une migration ratée se chiffre vite : journées de production perturbées, transactions à rejouer, équipes mobilisées, parfois pénalités contractuelles. Lorsque le client estime que ces coûts découlent d'une faute de modélisation ou d'un choix d'architecture, il se retourne contre vous.

La RC Pro Insurio intervient à deux niveaux. D'abord, elle prend en charge le dommage immatériel : chiffre d'affaires perdu, coûts de reprise des incidents transactionnels, préjudice financier directement imputable à votre prestation. Ensuite, elle finance votre défense : analyse du dossier, expertise technique contradictoire, négociation avec le client ou l'intégrateur. C'est souvent ce second volet qui pèse le plus lourd, car un litige technique sur une migration mobilise des compétences d'expertise coûteuses.

Pour un freelance, la couverture démarre à 18,90€/mois, un montant sans commune mesure avec le coût d'une seule journée de production interrompue chez un client fintech ou assurtech.