Applications métier critiques

Remplacer. Moderniser. Intégrer. Migrer.

Des besoins métier aux plateformes centrales prêtes pour la production. Une application centrale doit soutenir le modèle d’affaires de l’organisation — et non contraindre l’entreprise à contourner une technologie conçue pour une autre époque.

Tôt ou tard, la question se pose sous une forme que l’on ne peut plus repousser : le système central ne supporte plus les produits que l’entreprise veut vendre, les canaux que les clients attendent, les états que le régulateur demande, ou le rythme du marché. Le réflexe est d’aller regarder des produits. C’est la mauvaise première étape.

La transformation d’une plateforme centrale doit commencer par les capacités métier, les priorités, le modèle opérationnel cible, les besoins clients, les contraintes réglementaires et la stratégie technologique — pas par un catalogue de produits éditeurs. VODIS peut aider à traduire ces besoins en une stratégie applicative concrète, puis à porter cette stratégie jusqu’à la sélection, la modernisation, la mise en œuvre, la migration et la stabilisation.

Commencer par le métier que la plateforme doit servir

La première conversation porte sur le métier, pas sur le logiciel. Selon l’organisation, les facteurs déclencheurs d’une décision sur la plateforme centrale peuvent inclure :

de nouveaux produits et services que la plateforme actuelle ne sait pas exprimer
un time-to-market qui se compte en trimestres là où il devrait se compter en semaines
l’expérience client et les canaux digitaux
l’automatisation et le traitement de bout en bout
les volumes de transactions, l’échelle et les hypothèses de croissance
de nouveaux modèles de distribution, partenaires ou géographies
un reporting assemblé à la main plutôt que produit par le système
des exigences réglementaires que la plateforme ne sait pas démontrer
des données qui existent mais restent inaccessibles
des cas d’usage analytiques et d’IA bloqués par le modèle de données sous-jacent
l’intégration avec un écosystème qui a évolué sans elle
l’efficacité opérationnelle, la résilience et la réduction du coût et de la complexité

Toutes les organisations n’ont pas tous ces facteurs, et le supposer est une erreur. Le travail utile consiste à distinguer les deux ou trois qui imposent réellement la décision des nombreux qui sont simplement souhaitables. VODIS peut aider à traduire la stratégie métier en capacités, processus, parcours utilisateurs, produits et services, besoins d’information, besoins d’intégration et exigences non fonctionnelles — une base plus stable pour sélectionner ou concevoir la future plateforme qu’une liste de fonctionnalités demandées.

Comprendre l’existant avant de décider ce qui le remplacera

Il est remarquablement fréquent de lancer un programme de remplacement sans image partagée et à jour de la plateforme remplacée. L’évaluation de l’état actuel est ingrate et le plus souvent décisive. Selon la pertinence, elle peut couvrir :

les fonctionnalités métier réellement utilisées, par opposition à celles sous licence
l’architecture applicative et technique
la pile technologique et son horizon de support
les structures de données, leur qualité et leur propriété
les interfaces, les traitements batch et l’ordonnancement
les intégrations avec les systèmes environnants
les processus opérationnels et le modèle de support
la sécurité, la résilience, la performance et la scalabilité
la dépendance aux éditeurs et la dépendance aux compétences
les personnalisations, et la raison d’être initiale de chacune
la dette technique et les contournements historiques
les contraintes de version, de montée de version et de licence
la qualité et la sincérité de la documentation

Cette évaluation n’est pas un argument en faveur du remplacement. Elle peut parfaitement conclure que la plateforme existante est saine et que la vraie contrainte est ailleurs — dans les processus, les données, l’intégration ou le modèle opérationnel. Supposer que l’existant est mauvais est aussi peu utile que supposer qu’il va bien.

Cartographier l’écosystème autour du cœur

Une application centrale fonctionne rarement seule, et le coût d’un changement de cœur réside généralement dans tout ce qui y est raccordé. Selon l’organisation et son secteur, les dépendances pertinentes peuvent inclure :

les canaux digitaux et assistés
le CRM et les plateformes clients
les paiements, les cartes et le crédit
la trésorerie et le risque
la finance, la comptabilité et l’ERP
l’entrepôt, le lac ou la plateforme de données, et le reporting
les systèmes de reporting réglementaire et légal
l’identité, les accès et les habilitations
le workflow et la gestion documentaire
les services externes et les systèmes partenaires

Seuls les domaines réellement applicables méritent d’être cartographiés. Un schéma d’écosystème générique n’impressionne personne et ne décide rien.

Remplacer, moderniser ou faire évoluer ?

C’est la décision qui justifie cette page, et elle a trois réponses honnêtes plutôt qu’une seule à la mode :

REMPLACER / ACHETER — sélectionner et mettre en œuvre une nouvelle plateforme commerciale ou cloud, et accepter l’effort de migration et de conduite du changement associé
MODERNISER / RECONSTRUIRE — récupérer les fonctionnalités qui comptent vraiment et les réimplémenter sur une architecture moderne
FAIRE ÉVOLUER / INTÉGRER — conserver ce qui sert encore le métier, remplacer certains composants et faire évoluer l’architecture progressivement
HYBRIDE — en pratique, la plupart des programmes substantiels combinent deux de ces voies, séquencées dans le temps

Aucune de ces voies n’est universellement supérieure. Le remplacement n’est pas automatiquement meilleur que la modernisation, la modernisation n’est pas automatiquement meilleure que le remplacement, et la reconstruction assistée par IA n’est pas automatiquement appropriée. Quiconque vous indique la bonne voie avant d’avoir compris votre métier, vos données et vos contraintes vous vend quelque chose. La décision est un résultat de l’analyse, pas une donnée d’entrée.

Comment la décision se prend réellement

Lorsque c’est utile, VODIS peut structurer un cadre de décision comparant ACHETER, CONSTRUIRE, MODERNISER et HYBRIDE selon des critères qui comptent pour l’institution concernée :

adéquation métier et adéquation fonctionnelle
architecture, flexibilité et paramétrabilité
intégration et données
scalabilité, résilience et sécurité
contraintes réglementaires
risque de mise en œuvre et complexité de migration
le modèle opérationnel que la plateforme impose
dépendance éditeur, compétences et écosystème de mise en œuvre
modèle de version et de montée de version, et feuille de route produit
modèle commercial et coût total sur la durée de vie de la plateforme
considérations de sortie et de portabilité

La pondération est convenue avec le client pour le cas traité. Il n’existe pas de pondération universelle, et un cadre qui produit la même réponse pour toutes les institutions est un modèle, pas une analyse. Les livrables peuvent inclure une analyse d’options, les implications d’architecture et de delivery, une comparaison des risques, un modèle de coûts, des hypothèses de calendrier, une évaluation des dépendances et la justification d’une recommandation — mais aucun résultat n’est promis avant que le travail de découverte n’ait été fait.

Traduire les besoins métier en exigences sélectionnables

Les exigences sont la manière dont l’intention métier devient quelque chose face à quoi un éditeur peut être évalué. Les domaines qui comptent généralement :

exigences métier — ce que l’organisation doit pouvoir faire
exigences fonctionnelles — comment la plateforme doit le permettre
exigences techniques et de données
exigences d’intégration
exigences de sécurité et de résilience
exigences d’exploitation — comment la plateforme sera exploitée au quotidien
exigences de migration
exigences de sortie et de portabilité, définies au début plutôt qu’à la fin

L’objectif est la sélectionnabilité, pas l’exhaustivité. Un catalogue d’exigences qui tente de capturer chaque souhait devient un document d’achat que personne ne peut scorer et auquel aucun éditeur ne peut répondre utilement. La page que vous lisez n’est pas un modèle de cahier des charges, et le catalogue ne devrait pas l’être non plus.

Les exigences non fonctionnelles décident du comportement en production

L’adéquation fonctionnelle détermine si la plateforme peut faire le travail. Les exigences non fonctionnelles déterminent si elle survit au contact de la production :

attentes de disponibilité et de reprise
performance, capacité et scalabilité
sécurité et auditabilité
résilience et observabilité
maintenabilité et paramétrabilité
caractéristiques d’intégration et de déploiement
conservation et portabilité des données

Lorsque c’est praticable, elles doivent être rendues mesurables dans la mission elle-même, sur les volumes et les profils réels de l’institution — et non acceptées comme des adjectifs dans une réponse éditeur.

Sélectionner la plateforme — pas la meilleure présentation commerciale

La sélection est une discipline, et la qualité d’une démonstration est une preuve faible. VODIS peut accompagner :

l’étude de marché, la long list et la short list
la préparation du RFI et du RFP et un scoring structuré
les questionnaires éditeurs et un cadre d’évaluation
des scénarios de démonstration construits à partir des cas métier de l’institution
des scénarios de preuve de concept
une approche de prise de références qui pose des questions utiles
la revue d’architecture et la due diligence technique
la comparaison commerciale et l’analyse du coût total (TCO)

Un scoring produit dans une mission est une aide à la décision pour cette institution, sur ses propres critères pondérés. Ce n’est pas un classement sectoriel, il n’est pas transposable à une autre organisation, et VODIS ne représente, ne revend et ne perçoit de commission d’aucun éditeur de plateforme.

Évaluation indépendante des éditeurs

L’évaluation regarde au-delà de la liste de fonctionnalités, vers ce qui déterminera les dix prochaines années :

adéquation métier et fonctionnelle pour la gamme de produits réelle
architecture, API et ouverture
modèle cloud et modèle de déploiement
capacité d’intégration et architecture de données
paramétrabilité, et ce que coûte la personnalisation au moment des montées de version
l’écosystème de mise en œuvre et qui peut réellement le livrer
modèle opérationnel, sécurité et résilience
feuille de route, modèle de version et de montée de version, et viabilité de l’éditeur
risque de migration et dépendance à long terme
sortie et portabilité

Choisir sur le seul nombre de fonctionnalités est la manière dont les institutions finissent avec une plateforme qui coche toutes les cases et ne convient à rien. Aucune plateforme n’est la meilleure dans l’absolu ; l’adéquation est propre à l’institution.

Transformation du Core Banking

Le Core Banking est un domaine vertical pratique prioritaire pour ce service, reflétant l’expérience du fondateur dans la technologie bancaire et financière. Selon l’institution, une transformation Core Banking peut devoir traiter :

les dépôts, les comptes et la gestion des produits
le crédit et le cycle de vie des prêts
la tarification, les frais, les limites et les intérêts
les relations clients et tiers
la comptabilité et le traitement des transactions
les interfaces de paiement et les canaux
les interfaces de reporting réglementaire et financier
les traitements batch et de fin de journée
les données, les API et l’intégration
la disponibilité, la reprise et l’exploitation
la migration des soldes, des contrats et de l’historique

Aucune couverture par défaut de tous les produits bancaires ni de toutes les juridictions n’est revendiquée ; le périmètre est établi par mission. À titre d’illustration du marché et non de short list, le paysage pertinent comprend des plateformes établies telles que Temenos Transact, Oracle FLEXCUBE, Infosys Finacle et TCS BaNCS, aux côtés d’acteurs cloud-native tels que Mambu et Thought Machine Vault Core. Ces noms sont de simples exemples : ils ne sont pas classés, ne sont pas recommandés, et VODIS n’a aucune affiliation, aucun partenariat ni aucune relation de revente avec l’un d’eux. La short list appropriée dépend des exigences métier, d’architecture, réglementaires, opérationnelles et de migration de l’institution — raison pour laquelle cette page ne contient aucun classement d’éditeurs et ne cite aucune position d’analyste.

Au-delà du Core Banking

La même discipline s’applique à toute plateforme critique dont le métier dépend, plutôt qu’il ne l’utilise simplement :

CRM et plateformes clients — vue client, workflow commercial et de service, gestion des cas, support omnicanal
ERP et finance — finance, comptabilité, achats, contrôle de gestion, reporting
trésorerie et paiements
gestion des cartes et octroi de crédit
plateformes de risque et de conformité
plateformes de données et de reporting
applications centrales sectorielles, y compris l’assurance et le leasing

Lorsque l’illustration aide, le paysage entreprise comprend des plateformes telles que SAP S/4HANA, Oracle Fusion Cloud ERP et Microsoft Dynamics 365 pour l’ERP et la finance, et Salesforce et Microsoft Dynamics 365 pour le CRM — là encore comme exemples de marché, sans préférence exprimée et sans revendication de mise en œuvre pour aucun produit nommé. Aucune expertise sur tous les produits du marché n’est sous-entendue, et lorsqu’une catégorie est citée comme pertinente, elle l’est en tant que catégorie, non en tant que capacité déjà démontrée.

Choisir l’architecture et le modèle d’hébergement avec la plateforme

La sélection de l’éditeur et l’adéquation architecturale sont la même décision vue de deux côtés, et les séparer est la manière dont une institution acquiert une plateforme que son architecture ne peut absorber. La solution cible impose généralement des décisions sur :

l’architecture applicative, d’intégration et de données
l’identité, la sécurité et l’observabilité
le déploiement, les environnements et la résilience
le modèle opérationnel que l’architecture présuppose
la forme de déploiement — on-premises, cloud privé, cloud public, SaaS ou hybride
la réglementation, la sensibilité des données et la souveraineté
la latence, l’intégration et la capacité d’exploitation
la scalabilité, le modèle de coûts et le modèle éditeur
la sortie et la portabilité

Aucun modèle d’hébergement n’est toujours supérieur. Le cloud est une option avec des coûts, des dépendances et des contraintes, non une destination, et le SaaS échange du contrôle contre du rythme d’une manière que certaines institutions peuvent accepter et d’autres non. Dans les secteurs régulés, la résilience opérationnelle, le risque lié aux tiers TIC, les dispositifs d’externalisation et de cloud, la protection des données, les droits d’audit et d’accès et la planification de sortie doivent tous être établis au regard des exigences réellement applicables à cette institution, confirmées avec ses fonctions conformité et juridique et son autorité compétente. VODIS ne fournit pas de conseil juridique, ne certifie aucune conformité réglementaire et n’énonce pas d’exigences réglementaires de mémoire — ce sont des points à vérifier dans la mission, au regard des sources officielles en vigueur.

Sélectionner la solution — puis rendre le contrat exécutable

Un contrat signé n’est pas un contrat exécutable. Beaucoup de programmes héritent de leurs pires problèmes de clauses convenues avant que quiconque n’ait modélisé le déroulement réel des travaux. VODIS peut accompagner le client, aux côtés de ses propres conseils juridiques, sur :

la clarification du périmètre et le périmètre de mise en œuvre
la structure de licence, d’abonnement et de consommation
les environnements et leur coût
les responsabilités d’intégration et de migration — à qui revient chacune
le modèle de support, et les engagements de version et de montée de version
les exigences de niveau de service, les engagements techniques et d’architecture
les engagements de feuille de route et la manière dont ils sont démontrés
la propriété des données, les exigences de sortie et de portabilité
les dépendances de mise en œuvre et les obligations du client
le modèle commercial complet — frais de mise en œuvre, coûts d’environnements, support, montées de version, composants tiers, demandes de changement, prestations et coûts de sortie

Il s’agit d’un accompagnement à la négociation commerciale et technique. Ce n’est explicitement pas du conseil juridique : la revue contractuelle finale relève d’un conseil juridique qualifié, et VODIS ne remplace pas ce rôle ni n’y émet d’avis. Aucun prix client ou éditeur n’est publié, ici ou ailleurs.

La préparation à la mise en œuvre avant le jour un

Un contrat éditeur ne rend pas le client prêt à mettre en œuvre, et l’écart entre la signature et la préparation est là où les programmes perdent discrètement leurs six premiers mois. Être prêt signifie généralement :

gouvernance de programme, chantiers, rôles et droits de décision
gouvernance d’architecture et une autorité de conception qui se réunit réellement
environnements, accès, infrastructure et provisionnement cloud
prérequis de sécurité et d’intégration
préparation des données et de la migration engagée tôt, pas tard
approche de test convenue avant le début des tests
ressources métier nommées et libérées, pas seulement promises
onboarding des éditeurs et gouvernance éditeur
gestion des problèmes, des risques, des dépendances et des décisions
conduite du changement, formation et adoption
gouvernance de bascule et structure de commandement

Tous les programmes n’ont pas besoin d’un ensemble identique de chantiers, et importer une structure standard en bloc est un risque en soi. Cela rejoint étroitement la discipline décrite sous Gestion de programme et conduite du changement, sans la dupliquer : là le sujet est la gouvernance et l’adoption de la transformation en général, ici c’est la préparation d’un programme de plateforme spécifique.

La migration est un programme, pas une copie de données

La migration est l’endroit où les programmes centraux sont le plus souvent retardés, et elle est systématiquement sous-estimée parce qu’elle ressemble à une tâche technique. C’est un programme métier avec une composante technique :

découverte et profilage des données sources
nettoyage, mapping, transformation et règles de migration
stratégie d’historique, d’archivage et de conservation
outillage de migration et répétitions reproductibles
gestion des anomalies et validation métier
réconciliation — comptages, soldes, totaux, règles métier, comptes et contrats
traitement des exceptions et preuves d’audit
réconciliation de bascule et critères de validation

Pour les systèmes financiers en particulier, la migration doit être validée et non supposée : extraire, transformer, charger, réconcilier, corriger, recommencer — jusqu’à ce que les preuves permettent une bascule en production, pas avant. Une migration en une seule fois n’est pas un plan réaliste. Aucune personne compétente ne promet une absence totale de perte de données, et aucune norme réglementaire de réconciliation particulière n’est revendiquée ici — les contrôles applicables sont établis avec l’institution et ses auditeurs.

Le cœur fait partie d’un écosystème

Le cœur s’inscrit dans un paysage de canaux, CRM, paiements, cartes, trésorerie, risque, finance et reporting, et l’intégration est l’endroit où une décision de plateforme propre rencontre une réalité désordonnée. Les patterns utilisés peuvent inclure :

API et interfaces de service
événements et messagerie
fichiers et batch
middleware et plateformes d’intégration
coexistence entre l’ancienne et la nouvelle plateforme pendant la transition
synchronisation des données et système de référence pour chaque entité
routage, traitements dupliqués et réconciliation entre plateformes
parcours clients qui traversent les deux plateformes
reporting et support opérationnel tant que les deux sont en service

La coexistence est généralement la partie la plus sous-estimée d’une transformation par phases. Exploiter deux plateformes ne représente pas la moitié du travail d’en exploiter une ; pendant un temps, c’est davantage que l’une ou l’autre.

Tests, bascule et stabilisation

La mise en production est un événement opérationnel, pas une date de calendrier, et la décision d’y aller doit reposer sur des preuves plutôt que sur un engagement pris des mois plus tôt :

tests fonctionnels, d’intégration et de non-régression
tests de migration et de réconciliation des données
tests de performance, de sécurité et de résilience
recette utilisateur et préparation opérationnelle
répétition de bascule, plan, dépendances et gel
préparation métier, technique et éditeur, évaluées séparément
retour arrière et plan de secours, définis avant d’en avoir besoin
structure de commandement, communication et jalons de décision
stratégie de migration — par phases, produit par produit, par segment ou géographie, run parallèle, coexistence ou big-bang
hypercare, tri des anomalies, coordination éditeur et revue de performance
réconciliation, supervision opérationnelle et gestion du backlog
documentation et transition délibérée vers le run

Aucune approche n’est universellement juste : la migration par phases réduit certains risques et crée de la complexité de coexistence, le big-bang fait l’inverse. Toutes les catégories de tests ne sont pas obligatoires pour toutes les plateformes. Et personne ne peut promettre une absence totale d’interruption, une stabilisation sans incident, un calendrier de mise en œuvre garanti ou une réduction de coûts garantie — ce qui peut être fait, c’est rendre les risques visibles, les preuves réelles et les décisions délibérées. L’IA et l’automatisation peuvent aider à la génération de cas de test, à la conception de jeux de données, aux artefacts de non-régression, à l’analyse de couverture, à l’analyse des anomalies et à la documentation, mais la validation humaine de ce que les tests démontrent reste nécessaire.

Quand remplacer la plateforme n’est pas la seule option

Pour certaines applications critiques, il existe une seconde voie stratégique : comprendre, récupérer, reconcevoir, reconstruire, valider, migrer. Lorsqu’une application existante encode encore le métier mais ne peut plus le porter, l’archéologie logicielle assistée par IA peut aider à établir ce qui s’y trouve réellement avant que quiconque décide de ce qu’il faut préserver, reconcevoir ou supprimer :

compréhension du code et cartographie des dépendances
extraction des règles métier depuis le code, la configuration, le batch et les procédures stockées
découverte des interfaces et compréhension des structures de données
reconstruction des workflows et récupération de la documentation
génération de scénarios de test à partir du comportement observé
identification de la dette technique, et distinction entre règles à conserver et contournements historiques
réingénierie assistée par IA — génération de code cible, traduction entre langages et frameworks, refactoring, décomposition en composants, création d’API et documentation

Cela compte surtout pour les anciens systèmes centraux, où des règles critiques ne survivent souvent que dans le code, la configuration, le batch, les procédures stockées, les procédures opérationnelles et la mémoire de quelques spécialistes. L’IA peut aider à exposer ces règles ; les spécialistes métier et domaine doivent les valider. Aucune compréhension automatique parfaite n’est revendiquée, et il s’agit d’ingénierie assistée par IA et non de conversion automatique de système. Lorsque le code source ou les données sont sensibles, le travail peut être conçu autour d’une IA d’entreprise approuvée, d’un cloud maîtrisé, d’environnements privés ou d’une exécution locale des modèles, sous réserve de la politique de sécurité du client, de la classification des données et de l’architecture — même si tous les projets n’utilisent pas et n’ont pas besoin d’une IA privée. Cette voie rejoint naturellement la modernisation des systèmes cœur de métier historiques, où la compréhension profonde d’une application critique existante est le sujet en soi, et Product Innovation et Application Development lorsque de véritables nouveaux composants sont construits.

La responsabilité humaine ne se déplace pas

Pour une application critique, l’IA ne remplace ni l’architecture, ni la validation métier, ni l’expertise domaine, ni la revue de code, ni la revue de sécurité, ni les tests, ni la réconciliation, ni la validation opérationnelle, ni le contrôle de la migration, ni la décision de bascule. Elle change ce qu’une équipe compétente peut abattre ; elle ne change pas qui répond du résultat.

l’IA peut augmenter le levier d’ingénierie ; la responsabilité du système cible reste humaine
aucune migration de système entièrement autonome n’est proposée, et aucune ne devrait être acceptée
aucune réécriture de système entièrement autonome n’est proposée non plus
l’IA ne remplace ni les architectes, ni les développeurs, ni les testeurs, ni les experts métier, sur cette page comme en mission
toute production assistée par IA qui atteint une décision de production passe d’abord par une revue humaine

Ceci est énoncé clairement parce que l’inverse se vend actuellement, et parce qu’une plateforme centrale est précisément l’endroit où une règle générée par machine et non revue devient un problème financier ou réglementaire plutôt qu’un simple bug.

Comment VODIS travaille, et ce que vous pouvez recevoir

VODIS peut agir comme conseil senior du client, intégrateur de transformation, traducteur entre métier et technologie, coordinateur d’architecture, appui à la sélection d’éditeurs, couche de gouvernance de programme, coordinateur de la préparation à la mise en œuvre et appui à la gouvernance de migration et de bascule — une vision unique de la transformation, à travers le métier, la technologie et les éditeurs. VODIS peut réunir et coordonner une expertise senior métier, architecture, applicative, infrastructure, données, migration, sécurité et delivery selon le périmètre et les disponibilités.

les missions vont de l’évaluation de l’état actuel ou de la stratégie applicative, en passant par l’ingénierie des exigences, le RFI/RFP et le conseil en sélection de plateforme, jusqu’à la préparation à la mise en œuvre, la gouvernance de migration et de tests, la préparation de bascule et le redressement de programme
l’évaluation de modernisation, l’archéologie logicielle assistée par IA et la reconstruction assistée par IA sont disponibles comme missions à part entière
un leadership de transformation en intérim ou à temps partagé est possible lorsque l’organisation a besoin du rôle plutôt que du rapport
les modèles commerciaux incluent le conseil, le périmètre défini, la régie, le forfait géré et l’appui au programme
les livrables peuvent inclure un modèle de capacités métier, une évaluation de l’état actuel, une stratégie applicative, une architecture cible et un catalogue d’exigences
des supports RFI et RFP, une long list et une short list d’éditeurs, une matrice d’évaluation, des scénarios de démonstration et une comparaison commerciale ou de coût total
une évaluation de la préparation à la mise en œuvre, une structure de programme, des plans de migration et de migration de données, une architecture d’intégration, une stratégie de tests et de bascule, et un registre des risques et dépendances
des constats d’archéologie logicielle, un catalogue de règles métier et une feuille de route du système cible

Ce sont des exemples de ce qu’une mission peut produire, non une liste figée de livrables, et les spécialistes impliqués sont réunis par mission selon le périmètre et les disponibilités plutôt que tirés d’un large banc permanent — aucune capacité spécialiste illimitée ou garantie n’est sous-entendue. Les noms individuels, les noms de sociétés partenaires, les effectifs et les tarifs ne sont pas publiés. Lorsque l’expérience du fondateur est pertinente, elle est décrite comme des programmes dirigés ou coordonnés par le fondateur de VODIS dans de précédents rôles de direction et de management senior, avant la création de VODIS ; ces programmes ne sont pas présentés comme des réalisations clients de VODIS, et aucun client n’est nommé.

Si une application centrale ne soutient plus le métier, l’étape utile suivante n’est pas une démonstration produit. C’est une conversation sur ce que le métier attend de la plateforme, et un examen honnête de la question de savoir si la remplacer, la moderniser ou la faire évoluer est la bonne réponse.

Parlons de la transformation de vos applications centrales