Erreur n\u00b0 2 : tout migrer simplement parce que les donn\u00e9es existent<\/strong><\/p>\n Erreur n\u00b0 3 : supposer qu\u2019un export contient tout ce qui est visible dans l\u2019ancien syst\u00e8me<\/strong><\/p>\n Erreur n\u00b0 4 : vouloir tout changer en m\u00eame temps<\/strong><\/p>\n Erreur n\u00b0 5 : impliquer les utilisateurs trop tard<\/strong><\/p>\n La bonne nouvelle, c\u2019est qu\u2019aucune de ces erreurs n\u2019est in\u00e9vitable. La plupart peuvent \u00eatre \u00e9vit\u00e9es avant m\u00eame que le premier jeu de donn\u00e9es ne quitte l\u2019ancien syst\u00e8me.<\/p>\n La premi\u00e8re question \u00e0 se poser lors d\u2019une migration CAFM ne devrait pas \u00eatre : comment allons-nous extraire les donn\u00e9es ?<\/p>\n Elle devrait \u00eatre : pourquoi changeons-nous de syst\u00e8me ?<\/p>\n Il existe g\u00e9n\u00e9ralement une bonne raison. Le logiciel actuel n\u2019est peut-\u00eatre plus d\u00e9velopp\u00e9 ou pris en charge. Les co\u00fbts ont peut-\u00eatre augment\u00e9, certaines fonctionnalit\u00e9s importantes font d\u00e9faut, les rapports ne r\u00e9pondent plus aux besoins, le support est insuffisant ou les processus existants sont devenus inutilement complexes.<\/p>\n Quelle que soit la raison, elle doit guider la suite du projet.<\/p>\n Si le syst\u00e8me actuel complique inutilement la maintenance, la migration doit permettre de l\u2019am\u00e9liorer. Si les informations sont difficiles \u00e0 trouver, la nouvelle solution doit en faciliter l\u2019acc\u00e8s et l\u2019utilisation. Si la cr\u00e9ation de rapports r\u00e9currents n\u00e9cessite encore plusieurs exports, des corrections manuelles et le rapprochement d\u2019informations provenant de diff\u00e9rentes sources, la migration est l\u2019occasion id\u00e9ale de se demander pourquoi.<\/p>\n Sans objectifs clairement d\u00e9finis, il est pourtant \u00e9tonnamment facile de reproduire l\u2019existant.<\/p>\n Les m\u00eames structures sont conserv\u00e9es. Les m\u00eames processus perdurent. Et parfois, m\u00eame les m\u00eames solutions de contournement trouvent leur place dans le nouveau syst\u00e8me.<\/p>\n Le syst\u00e8me est nouveau. Les raisons qui avaient conduit \u00e0 remplacer l\u2019ancien, elles, sont toujours l\u00e0.<\/p>\n Avant d\u2019aborder les d\u00e9tails de la migration, d\u00e9finissez ce qui doit r\u00e9ellement s\u2019am\u00e9liorer apr\u00e8s le changement.<\/p>\n Identifiez les faiblesses de la situation actuelle, d\u00e9terminez quels processus doivent \u00eatre am\u00e9lior\u00e9s et convenez des exigences essentielles pour les op\u00e9rations futures. D\u00e9finissez ensuite comment vous pourrez v\u00e9rifier que le changement a effectivement produit les r\u00e9sultats attendus.<\/p>\n Le projet dispose ainsi d\u2019un point de r\u00e9f\u00e9rence clair pour toutes les d\u00e9cisions qui suivront.<\/p>\n Une id\u00e9e \u00e9tonnamment tenace revient dans les projets de migration : si une donn\u00e9e existe, c\u2019est forc\u00e9ment qu\u2019elle est importante.<\/p>\n Le raisonnement est compr\u00e9hensible. Apr\u00e8s tout, quelqu\u2019un l\u2019a saisie, mise \u00e0 jour ou import\u00e9e un jour. Il devait bien y avoir une raison.<\/p>\n Peut-\u00eatre. En 2014.<\/p>\n Les bases de donn\u00e9es CAFM s\u2019enrichissent au fil des ann\u00e9es. Les b\u00e2timents \u00e9voluent, les espaces sont r\u00e9organis\u00e9s, les \u00e9quipements sont remplac\u00e9s, les contrats arrivent \u00e0 \u00e9ch\u00e9ance et les responsabilit\u00e9s changent. Les conventions de nommage \u00e9voluent elles aussi, et les informations peuvent \u00eatre g\u00e9r\u00e9es diff\u00e9remment selon les services ou les sites. Certaines donn\u00e9es sont soigneusement tenues \u00e0 jour. D\u2019autres sont toujours l\u00e0 principalement parce que personne n\u2019a jamais eu de raison de les remettre en question.<\/p>\n Et tous les probl\u00e8mes ne sont pas visibles \u00e0 l\u2019\u00e9chelle d\u2019un enregistrement individuel.<\/p>\n Un \u00e9quipement peut, par exemple, \u00eatre indiqu\u00e9 comme hors service alors que des op\u00e9rations de maintenance actives lui sont encore attribu\u00e9es. Pris s\u00e9par\u00e9ment, les deux enregistrements peuvent sembler parfaitement valides. Mais lequel refl\u00e8te la r\u00e9alit\u00e9 ? Il faut le d\u00e9terminer avant de d\u00e9cider ce qui sera transf\u00e9r\u00e9 dans le nouveau syst\u00e8me.<\/p>\n Tout migrer simplement parce que les donn\u00e9es sont disponibles peut sembler \u00eatre l\u2019option la plus s\u00fbre. Rien ne se perd et aucune d\u00e9cision difficile ne doit \u00eatre prise avant le transfert. Le probl\u00e8me, c\u2019est que le nouveau syst\u00e8me risque alors de commencer sa vie op\u00e9rationnelle avec les informations obsol\u00e8tes, contradictoires ou inutiles h\u00e9rit\u00e9es de l\u2019ancien.<\/p>\n Toutes les informations ne m\u00e9ritent donc pas le m\u00eame traitement. Selon leur pertinence, leur qualit\u00e9 et leur utilit\u00e9 future, les donn\u00e9es peuvent \u00eatre transf\u00e9r\u00e9es directement, nettoy\u00e9es ou consolid\u00e9es, conserv\u00e9es dans une archive ou d\u00e9lib\u00e9r\u00e9ment laiss\u00e9es de c\u00f4t\u00e9. Dans certains cas, repartir sur une base de donn\u00e9es propre peut \u00eatre plus pertinent que de transf\u00e9rer des informations obsol\u00e8tes ou incompl\u00e8tes.<\/p>\n Il ne s\u2019agit pas de r\u00e8gles automatiques. Un \u00ab \u00e9quipement actif \u00bb ne doit pas n\u00e9cessairement \u00eatre transf\u00e9r\u00e9 dans le nouveau syst\u00e8me simplement parce que son statut indique qu\u2019il est actif. De la m\u00eame mani\u00e8re, un ancien enregistrement ne doit pas automatiquement \u00eatre archiv\u00e9 uniquement en raison de son \u00e2ge. Sa finalit\u00e9, sa qualit\u00e9, ses d\u00e9pendances et son utilisation future doivent \u00e9galement \u00eatre prises en compte.<\/p>\n D\u00e9cidez quelles donn\u00e9es doivent faire partie de la migration et dans quel \u00e9tat elles doivent arriver.<\/p>\n V\u00e9rifiez quelles informations sont encore pertinentes, quels enregistrements sont obsol\u00e8tes ou incomplets, o\u00f9 se trouvent les doublons et quels jeux de donn\u00e9es n\u2019ont pas \u00e9t\u00e9 tenus \u00e0 jour de mani\u00e8re fiable.<\/p>\n Demandez-vous si les donn\u00e9es historiques sont r\u00e9ellement n\u00e9cessaires aux futurs processus ou si elles doivent simplement rester accessibles \u00e0 des fins de documentation ou de conformit\u00e9.<\/p>\n Transf\u00e9rer correctement des donn\u00e9es dont la fiabilit\u00e9 est douteuse ne les rend pas plus fiables. Cela signifie simplement que le transfert a fonctionn\u00e9.<\/p>\n \u00ab Nous avons les donn\u00e9es. \u00bb<\/p>\n Cette phrase est moins rassurante qu\u2019elle n\u2019en a l\u2019air.<\/p>\n Ce que les utilisateurs voient dans un syst\u00e8me CAFM \u00e9tabli ne correspond pas n\u00e9cessairement \u00e0 ce qui peut en \u00eatre extrait. Les informations affich\u00e9es dans l\u2019application peuvent d\u00e9pendre de tables li\u00e9es, de valeurs calcul\u00e9es ou de la logique interne du syst\u00e8me. Un export peut contenir les diff\u00e9rents enregistrements sans inclure les identifiants et les relations qui leur donnent tout leur sens.<\/p>\n Prenons l\u2019exemple d\u2019une porte coupe-feu. Dans l\u2019ancien syst\u00e8me, son emplacement, son calendrier d\u2019inspection, le prestataire responsable et le dernier rapport d\u2019inspection peuvent \u00eatre accessibles depuis un m\u00eame enregistrement. En arri\u00e8re-plan, ces informations peuvent toutefois \u00eatre stock\u00e9es dans diff\u00e9rentes tables ou reli\u00e9es par des r\u00e9f\u00e9rences internes. Si l\u2019export contient les diff\u00e9rents enregistrements, mais pas ces r\u00e9f\u00e9rences, la porte et le document sont bien pr\u00e9sents, sans qu\u2019il soit possible de les relier de mani\u00e8re fiable.<\/p>\n Les donn\u00e9es ont \u00e9t\u00e9 extraites. Le contexte qui leur donnait leur utilit\u00e9, lui, ne l\u2019a pas \u00e9t\u00e9.<\/p>\n Et extraire les informations ne repr\u00e9sente que la moiti\u00e9 du travail.<\/p>\n M\u00eame un export complet doit encore pouvoir s\u2019int\u00e9grer dans le syst\u00e8me cible. Les champs, classifications, valeurs de statut, identifiants et hi\u00e9rarchies peuvent y \u00eatre structur\u00e9s diff\u00e9remment. Une valeur source telle que \u00ab Statut 3 \u00bb ne peut pas simplement \u00eatre transf\u00e9r\u00e9e si sa signification dans le syst\u00e8me cible n\u2019a pas \u00e9t\u00e9 d\u00e9finie. Il en va de m\u00eame pour les relations : savoir que deux enregistrements sont li\u00e9s ne suffit pas \u00e0 indiquer au nouveau syst\u00e8me comment repr\u00e9senter cette relation.<\/p>\n Travaillez rapidement avec un v\u00e9ritable export de donn\u00e9es au lieu de vous fier uniquement \u00e0 ce qui est visible dans l\u2019application.<\/p>\n V\u00e9rifiez quels identifiants, classifications, affectations et relations sont r\u00e9ellement disponibles en dehors de l\u2019ancien syst\u00e8me. Clarifiez l\u2019acc\u00e8s \u00e0 la base de donn\u00e9es, les possibilit\u00e9s d\u2019export, les interfaces et la documentation technique avant que la migration n\u2019en d\u00e9pende.<\/p>\n D\u00e9finissez ensuite comment les informations extraites doivent \u00eatre repr\u00e9sent\u00e9es dans le syst\u00e8me cible. Le mapping d\u00e9termine o\u00f9 chaque information doit \u00eatre plac\u00e9e, tandis que les r\u00e8gles de transformation d\u00e9finissent comment les valeurs doivent \u00eatre interpr\u00e9t\u00e9es ou converties. Les relations et les exceptions doivent elles aussi suivre des r\u00e8gles clairement d\u00e9finies.<\/p>\n Et testez ces r\u00e8gles avant le transfert final.<\/p>\n Commencez avec un jeu de donn\u00e9es repr\u00e9sentatif, effectuez la migration et validez le r\u00e9sultat. Si, par exemple, un ensemble d\u00e9fini d\u2019\u00e9quipements techniques doit \u00eatre transf\u00e9r\u00e9, vous devez pouvoir v\u00e9rifier ce qui est effectivement arriv\u00e9 dans le nouveau syst\u00e8me et expliquer les \u00e9ventuelles diff\u00e9rences.<\/p>\n Si quelque chose ne va pas, corrigez les donn\u00e9es sources ou la r\u00e8gle de migration \u00e0 l\u2019origine du probl\u00e8me plut\u00f4t que de modifier individuellement les enregistrements dans le syst\u00e8me cible. Relancez ensuite la migration.<\/p>\n Une correction qui dispara\u00eet au prochain cycle de migration n\u2019a jamais vraiment \u00e9t\u00e9 une correction.<\/p>\n Identifier ces limites pendant la phase de test vous laisse le temps de les r\u00e9soudre.<\/p>\n Un nouveau syst\u00e8me CAFM ouvre de nouvelles possibilit\u00e9s.<\/p>\n Et les possibilit\u00e9s ont une f\u00e2cheuse tendance \u00e0 se transformer en exigences de projet.<\/p>\n Puisque l\u2019organisation migre d\u00e9j\u00e0 vers un nouveau syst\u00e8me, pourquoi ne pas en profiter pour repenser la maintenance ? Et introduire des processus mobiles. Et reconstruire les interfaces. Et restructurer la gestion des contrats. Et nettoyer vingt ans de donn\u00e9es historiques. Et peut-\u00eatre modifier quelques workflows puisque tout le monde est d\u00e9j\u00e0 mobilis\u00e9.<\/p>\n Toutes ces mesures peuvent \u00eatre pertinentes.<\/p>\n Les mettre toutes en \u0153uvre simultan\u00e9ment ne l\u2019est pas forc\u00e9ment.<\/p>\n Chaque sujet suppl\u00e9mentaire semble g\u00e9rable lorsqu\u2019il est consid\u00e9r\u00e9 s\u00e9par\u00e9ment. Mais lorsque suffisamment de sujets sont regroup\u00e9s dans une m\u00eame phase du projet, le fameux \u00ab tant qu\u2019on y est \u00bb finit par peser lourd.<\/p>\n \u00c0 mesure que le p\u00e9rim\u00e8tre s\u2019\u00e9largit, les d\u00e9pendances se multiplient. Une modification dans un domaine peut remettre en question des d\u00e9cisions d\u00e9j\u00e0 prises ailleurs. Si les exigences continuent elles aussi d\u2019\u00e9voluer, certaines d\u00e9cisions doivent \u00eatre r\u00e9examin\u00e9es, des travaux d\u00e9j\u00e0 r\u00e9alis\u00e9s doivent \u00eatre adapt\u00e9s et l\u2019ensemble de la mise en \u0153uvre devient de plus en plus difficile \u00e0 ma\u00eetriser.<\/p>\n D\u00e9terminez ce qui est indispensable pour d\u00e9marrer sur des bases fiables et ce qui peut \u00eatre mis en \u0153uvre ult\u00e9rieurement.<\/p>\n Les structures fondamentales et les donn\u00e9es essentielles peuvent \u00eatre trait\u00e9es en premier. Les processus, interfaces et fonctionnalit\u00e9s suppl\u00e9mentaires peuvent ensuite \u00eatre introduits progressivement, selon des \u00e9tapes coh\u00e9rentes. Cela ne r\u00e9duit pas n\u00e9cessairement l\u2019ampleur globale du projet. Cela permet de rendre un projet complexe ma\u00eetrisable.<\/p>\n Surtout, cette approche permet d\u2019obtenir rapidement des r\u00e9sultats utilisables. Un processus peut \u00eatre mis en place, test\u00e9, \u00e9valu\u00e9 et ajust\u00e9 avant de passer au prochain grand ensemble de fonctionnalit\u00e9s.<\/p>\n Il existe une diff\u00e9rence consid\u00e9rable entre entendre dire qu\u2019un projet avance et pouvoir d\u00e9j\u00e0 utiliser ses premiers r\u00e9sultats.<\/p>\n Mais une mise en \u0153uvre par \u00e9tapes ne fonctionne que si les responsabilit\u00e9s d\u00e9cisionnelles sont clairement d\u00e9finies. Quelqu\u2019un doit pouvoir trancher sur les exigences m\u00e9tier. Quelqu\u2019un doit les hi\u00e9rarchiser. Quelqu\u2019un doit r\u00e9soudre les questions li\u00e9es aux donn\u00e9es et valider les modifications.<\/p>\n Les intitul\u00e9s de poste varieront d\u2019une organisation \u00e0 l\u2019autre. L\u2019essentiel est que, lorsqu\u2019une d\u00e9cision doit \u00eatre prise, chacun sache qui est habilit\u00e9 \u00e0 la prendre.<\/p>\n Il existe un moyen tr\u00e8s simple de rep\u00e9rer les probl\u00e8mes dans un processus parfaitement con\u00e7u sur le papier : le confier \u00e0 quelqu\u2019un qui devra r\u00e9ellement l\u2019utiliser.<\/p>\n Les personnes qui travaillent quotidiennement avec un syst\u00e8me CAFM remarquent des d\u00e9tails qui passent facilement inaper\u00e7us lors des ateliers ou sur les sch\u00e9mas de processus. Un champ est mal plac\u00e9. Une information importante est trop longue \u00e0 trouver. Un workflow qui semblait parfaitement logique pendant la conception se r\u00e9v\u00e8le inutilement complexe au quotidien.<\/p>\n Si les utilisateurs d\u00e9couvrent le nouveau syst\u00e8me peu avant la mise en production, ces constats arrivent bien tard.<\/p>\n \u00c0 ce stade, les processus sont d\u00e9j\u00e0 configur\u00e9s, les d\u00e9cisions ont \u00e9t\u00e9 prises et des modifications qui auraient \u00e9t\u00e9 relativement simples trois mois auparavant ont soudain des r\u00e9percussions sur la formation, la documentation, les tests et le calendrier du projet.<\/p>\n Impliquez les futurs utilisateurs suffisamment t\u00f4t pour que leurs retours puissent r\u00e9ellement \u00eatre pris en compte.<\/p>\n Leur pr\u00e9senter des r\u00e9sultats interm\u00e9diaires leur permet de v\u00e9rifier comment les nouvelles structures et les nouveaux processus fonctionnent en pratique et de signaler des probl\u00e8mes qui ne sont pas n\u00e9cessairement visibles d\u2019un point de vue technique.<\/p>\n Ils n\u2019ont pas besoin d\u2019assister \u00e0 toutes les r\u00e9unions. En revanche, des moments pr\u00e9cis doivent \u00eatre pr\u00e9vus tout au long de la migration pour recueillir leurs retours. Ils peuvent ainsi se familiariser progressivement avec le nouvel environnement au lieu de le d\u00e9couvrir pour la premi\u00e8re fois juste avant la mise en production.<\/p>\n La r\u00e9ussite d\u2019une migration CAFM ne devrait pas \u00eatre \u00e9valu\u00e9e en fonction du volume de donn\u00e9es transf\u00e9r\u00e9es. Ce qui compte, c\u2019est que le nouveau syst\u00e8me d\u00e9marre avec des informations fiables, des relations pertinentes entre les donn\u00e9es et moins de probl\u00e8mes h\u00e9rit\u00e9s de l\u2019ancien environnement.<\/p>\n <\/p>\n Chez speedikon FM AG, nous accompagnons nos clients \u00e0 chaque \u00e9tape de leur migration en mettant notre exp\u00e9rience au service des exigences, des d\u00e9pendances et des conditions techniques propres \u00e0 chaque projet. Avec speedikon\u00ae C<\/em><\/strong>, les donn\u00e9es, les processus et les informations pertinentes peuvent \u00eatre regroup\u00e9s dans un environnement logiciel int\u00e9gr\u00e9, offrant ainsi une base flexible pour les op\u00e9rations futures.<\/p>\n Vous envisagez de remplacer votre syst\u00e8me CAFM actuel ? Contactez nos experts<\/a> pour \u00e9changer sur votre projet de migration.<\/p>\n Vous souhaitez approfondir le sujet ? Notre livre blanc vous accompagne \u00e0 travers les principales \u00e9tapes d\u2019un changement de syst\u00e8me, de la d\u00e9finition des objectifs et de l\u2019\u00e9valuation des donn\u00e9es existantes jusqu\u2019au mapping, aux tests, \u00e0 la validation et au cutover.<\/p>\nErreur n\u00b0 1 : commencer sans avoir clairement d\u00e9fini les raisons du changement de syst\u00e8me<\/strong><\/h2>\n
Comment \u00e9viter cette erreur<\/strong><\/h3>\n
Erreur n\u00b0 2 : tout migrer simplement parce que les donn\u00e9es existent<\/strong><\/h2>\n
Quelles donn\u00e9es doivent r\u00e9ellement \u00eatre transf\u00e9r\u00e9es ?<\/strong><\/h3>\n
![\"Aper\u00e7u](\"https:\/\/www.charlyverse.com\/wp-content\/uploads\/2026\/09\/Charlyverse_CAFM_Migration_Tabelle_eng.jpg\")
<\/p>\nComment \u00e9viter cette erreur<\/strong><\/h3>\n
Erreur n\u00b0 3 : supposer qu\u2019un export contient tout ce qui est visible dans l\u2019ancien syst\u00e8me<\/strong><\/h2>\n
Comment \u00e9viter cette erreur<\/strong><\/h3>\n
Erreur n\u00b0 4 : vouloir tout changer en m\u00eame temps<\/strong><\/h2>\n
Comment \u00e9viter cette erreur<\/strong><\/h3>\n
Erreur n\u00b0 5 : impliquer les utilisateurs trop tard<\/strong><\/h2>\n
Comment \u00e9viter cette erreur<\/strong><\/h3>\n
Une meilleure migration commence par de meilleures d\u00e9cisions<\/strong><\/h2>\n
![\"Illustration](\"https:\/\/www.charlyverse.com\/wp-content\/uploads\/2026\/09\/Charlyverse_CAFM_Migration_Grafik_eng.jpg\")
Pour aller plus loin avec notre livre blanc<\/strong><\/h2>\n