AccueilServicesMigration et montée de version Ivalua : l’évaluation, puis la migration

Migration et montée de version Ivalua : l’évaluation, puis la migration

La difficulté d’une montée de version Ivalua dépend de deux choses : l’écart de votre paramétrage et de vos interfaces au standard, et le nombre de versions sautées. Une évaluation d’une à deux semaines, à partir de 7 500 €, mesure les deux et donne le plan avant la migration.

Qui a besoin d’une évaluation avant une montée de version Ivalua ?

Les équipes qui ont des versions de retard, ou dont la montée de version perd sans cesse sa place dans la feuille de route. Aussi celles qui se demandent s’il faut monter de version sur place ou reconstruire une solution plus propre sur la nouvelle version. La migration de SAP Ariba vers Ivalua est un autre sujet, traité dans un guide en préparation.

À quelle fréquence Ivalua impose-t-il une montée de version ?

Dans les conditions standard d’Ivalua, au moins une fois tous les deux ans, avec une montée de version recommandée tous les 12 à 18 mois. Ces conditions sont publiées dans un contrat public américain : le contrat-cadre signé par Ivalua avec l’État du Maine, via la centrale NASPO ValuePoint, en 2023.

RègleCe que disent les conditions
FréquenceAu moins une montée de version tous les 12 à 18 mois recommandée ; au moins une tous les deux ans exigée
Version cibleEn général l’une des deux dernières versions publiées, et uniquement une version disponible (GA)
LimiteUne montée de version par période de 12 mois, sauf accord des deux parties
Ce qui est inclusLes ressources d’Ivalua nécessaires à la montée de version sont comprises dans l’abonnement
Ce qui est facturéLes nouvelles fonctions ou modules peuvent demander du travail en plus ; les spécifiques, paramétrages complexes et intégrations ajoutés après la mise en production sont facturés à chaque montée de version
Gel des évolutionsAucune évolution pendant toute la montée de version ; un gel plus court coûte des frais de fusion et de nouvelle recette
PrérequisDes scripts de test détaillés rédigés par le client, un plan projet signé, les charges inscrites dans un SOW (document contractuel de cadrage)
En cas de retardIvalua n’est pas responsable des anomalies, des failles de sécurité ni du non-respect du SLA tant que le client n’est pas en conformité
Les règles de montée de version dans les conditions standard d’Ivalua (2023)

Le coût d’une montée de version se loge dans vos spécifiques et dans les versions sautées ; les conditions le disent.

Source : les conditions standard d’Ivalua dans un contrat public américain, contrat-cadre MA 18P 23081100000000000020, en vigueur depuis août 2023. Votre propre contrat peut différer ; l’évaluation le lit.

Une montée de version Ivalua est-elle difficile ?

Cela va d’une simple étape technique à un vrai projet. Selon les conditions d’Ivalua, la durée peut se compter en jours, en semaines ou en mois. Elle dépend de la complexité de l’implémentation (spécifiques, paramétrages complexes, variantes régionales, interfaces non standard, nombre de modules) et du nombre de versions sautées, certaines versions imposant une refonte ou une migration. Pour une montée de version courte, Ivalua recommande lui-même de rester sur le standard et de monter de version régulièrement.

Côté léger, l’EPFL est passée de la version 170 à la 178 avec une coupure du service du mercredi 16 h 30 au jeudi matin, mise en production le 27 juin 2024 : un changement de version technique, sans nouvelle fonction, les fonctions propres à l’EPFL inchangées (actualité EPFL).

Qu’est-ce qui casse lors d’une montée de version Ivalua ?

Ce que les conditions standard désignent comme coûteux est aussi ce qui demande le plus de recette :

  • Les paramétrages spécifiques et objets personnalisés ajoutés après la mise en production : chacun doit être repris et recetté à nouveau.
  • Les interfaces non standard, surtout avec l’ERP : un message ou une règle qui change se traduit par des commandes ou des factures rejetées.
  • Les workflows chargés d’exceptions, et les alertes, requêtes et rapports spécifiques qui dépendent du modèle de données.
  • Les versions sautées : plus le saut est grand, plus les refontes et migrations imposées s’accumulent.
  • Vos propres évolutions : le gel les arrête, le métier doit donc s’organiser en conséquence.

Comment préparer une montée de version Ivalua ?

  1. Lister les paramétrages spécifiques, objets personnalisés, interfaces et rapports, et décider pour chacun : garder, simplifier ou abandonner.
  2. Rédiger ou mettre à jour les scénarios de non-régression ; les conditions en font un prérequis.
  3. Contrôler les données qui vont migrer : doublons fournisseurs, statuts, fiches que la nouvelle version traitera autrement.
  4. Cartographier les interfaces avec l’ERP et les autres systèmes, et planifier leur recette de bout en bout avec les équipes en face.
  5. Fixer le gel des évolutions avec le métier et les sponsors, et signer le plan projet.
  6. Choisir la version cible et l’approche : montée de version sur place, ou nouvelle solution construite sur la nouvelle version.

Quelle expérience de migration Ivalua ai-je ?

Trois cycles complets sur la même plateforme de groupe chez BNP Paribas, dont deux ont tranché entre reprendre le paramétrage existant et le reconstruire :

VersionApprochePourquoi, et ce que j’ai fait
v156Construction et déploiementConstruction et déploiement de la plateforme S2P du groupe : fournisseurs, sourcing, CLM, catalogue, BPM, e-procurement, avec de nombreux paramétrages spécifiques complexes
v164Refonte complète, reconstruite de zéroLa v156 portait de nombreux paramétrages spécifiques complexes ; la refonte les a remis à plat et simplifiés, et a redessiné les workflows. Livrée dans le budget et dans les délais
v182Nouvelle solution construite de zéro, au départ de la v164Les chantiers de reprise de données de bout en bout : contrôles de qualité, détection des doublons, documentation des flux jusqu’à la validation. Livrée dans les délais, toujours en évolution, en double run pendant la bascule des entités et des utilisateurs
BNP Paribas : trois versions d’Ivalua, trois approches

Deux cycles sur trois ont choisi la reconstruction plutôt que la reprise du paramétrage.

Le détail est dans les études de cas : v164 et v182.

Que livre l’évaluation, et combien coûte-t-elle ?

  • L’inventaire : paramétrages spécifiques, objets personnalisés, interfaces et rapports, chacun avec une recommandation garder, simplifier ou abandonner.
  • L’analyse d’impact : ce que les versions entre la vôtre et la version cible changent pour votre paramétrage et vos interfaces.
  • L’approche : montée de version sur place ou reconstruction, avec ses raisons.
  • Le plan : scénarios de test à rédiger, données à nettoyer, interfaces à recetter, gel des évolutions et enchaînement.

L’évaluation dure une à deux semaines et coûte à partir de 7 500 € HT, au forfait. La migration elle-même est sur mesure et chiffrée sur le plan : je peux la mener en mission senior ou avec une équipe Ivalua que je pilote.

Questions fréquentes

Combien de temps dure une montée de version Ivalua ?

Les conditions standard d’Ivalua parlent de jours, de semaines ou de mois. La durée dépend de la complexité de l’implémentation et du nombre de versions sautées. Une montée de version technique sur un paramétrage proche du standard peut être courte ; un saut de plusieurs versions avec de nombreux spécifiques est un projet à part entière.

Que se passe-t-il si l’on saute des montées de version ?

Selon les conditions standard d’Ivalua publiées dans un contrat public américain, le client doit monter de version au moins une fois tous les deux ans, et Ivalua n’est pas responsable des anomalies, des failles de sécurité ni du non-respect du SLA tant que le client n’est pas en conformité. Chaque version sautée alourdit aussi la suivante.

Faut-il monter de version sur place ou reconstruire ?

Sur place quand le paramétrage correspond toujours au métier et reste proche du standard. Une reconstruction se discute quand les spécifiques se sont accumulés : chez BNP Paribas, la plateforme a été reconstruite de zéro en v164 pour cette raison, et la v182 a de nouveau été une nouvelle solution. L’évaluation donne la recommandation et ses raisons.

Quelle certification Ivalua exige-t-il pour paramétrer la plateforme ?

Dans les conditions standard d’Ivalua, quiconque paramètre la plateforme doit être certifié Ivalua niveau 2, et niveau 3 pour les intégrations ; à défaut, le prestataire mandaté par le client doit être un partenaire certifié Ivalua. La règle vaut pour tout paramétrage, montées de version comprises. Je suis certifié Ivalua L1, L2 et L3.

Le gel des évolutions arrête-t-il le métier ?

Il arrête les modifications de la plateforme, pas son utilisation. Pendant la montée de version, aucune évolution n’est construite et les demandes en attente patientent. L’évaluation planifie ce gel avec le métier, pour que les évolutions urgentes partent avant qu’il ne commence.

30 minutes. Votre projet, mon avis franc.

Dites-moi où en est le programme. Vous repartez avec une lecture du risque et la prochaine étape, que l’on travaille ensemble ou non.