Les données non structurées sont la moitié la plus difficile du retrait d’une ancienne plateforme. Quand les documents sont au cœur du travail quotidien, l’objectif est une migration que les utilisateurs ne remarquent jamais, et le risque se loge ailleurs que dans le code.
Retirer un CRM en conservant ses données, c’est la moitié structurée de l’abandon d’une ancienne plateforme. L’autre moitié, non structurée, ce sont les documents : les formulaires signés, les relevés et la correspondance qu’une entreprise réglementée doit pouvoir produire sur demande.
Dans une mission récente, ces documents se trouvent dans une ferme SharePoint sur site, présentée au personnel par un panneau documentaire intégré à Dynamics 365. Le personnel ouvre un client ou un dossier, voit quels documents sont requis et lesquels existent, et travaille avec eux sans jamais savoir que SharePoint est en jeu. La ferme doit disparaître. Le panneau, et la façon dont les gens s’en servent, doivent rester exactement tels quels.
Nous avons commencé par une revue d’architecture du service existant, et le constat le plus utile était rassurant. Toutes les opérations sur SharePoint passaient déjà par une seule interface d’accès aux données, et une seconde implémentation de cette interface, écrite pour SharePoint Online, existait déjà et était compilée sur chaque branche. Le choix de celle qui s’exécute tient à un seul enregistrement dans chaque hôte.
La migration n’est donc pas une réécriture. Rien de ce que touchent les utilisateurs n’a besoin de changer. Elle se ramène à un identifiant, un pipeline de mise en production, une configuration de recherche, un ensemble d’enregistrements sources et un transfert de données.
Cela a aussi rendu le reste de la revue honnête. Une fois que l’on sait que la modification du code est minime, il devient évident que le risque se trouve ailleurs.
Identité. SharePoint Online n’accepte pas le type de jeton app-only qu’utilisait l’ancienne intégration. Il exige une authentification par certificat via Entra ID. Le code de ce chemin a été écrit et testé bien avant la délivrance du certificat lui-même, si bien qu’une simple tâche d’administration est restée l’unique dépendance bloquante de toute la migration jusqu’à sa levée en août.
Recherche. Le panneau s’appuie sur la recherche pour trouver les documents. Dans SharePoint Online, les propriétés gérées dont dépend la recherche doivent exister dans le schéma du locataire, et les bibliothèques cibles doivent porter des colonnes dont les noms internes correspondent exactement à ceux qu’écrit le service. Une erreur sur l’un ou l’autre point, et la recherche ne renvoie plus rien, sans le moindre message.
Limitation des requêtes. SharePoint Online se protège bien plus agressivement qu’une ferme sur site. Une recherche qui se démultiplie en nombreuses requêtes parallèles fonctionne sur site et se fait limiter dans le cloud : il faut donc plafonner la concurrence avant de lancer toute validation en masse.
Mécanique de mise en production. La compilation produisait déjà la version en ligne du service, mais au départ rien ne la déployait. L’ajouter a touché à la fois la définition du pipeline et la définition de mise en production, exactement le genre de petite modification qui tourne mal quand elle est faite dans la précipitation.
Une décision de conception rend la bascule plus sûre qu’elle ne le serait autrement. Les points de terminaison SharePoint qu’utilise le service sont stockés dans une table de base de données, gérée depuis le site d’administration du système lui-même. Un environnement peut être redirigé vers les nouvelles bibliothèques, puis ramené en arrière en cas de problème, sans déploiement.
La bascule cesse ainsi d’être un événement unique et irréversible pour devenir une étape maîtrisée avec un chemin de retour, ce que toute personne responsable de documents réglementés est en droit d’attendre.
Avant de migrer quoi que ce soit qui soit au cœur du travail quotidien, vérifiez s’il existe un point de jonction unique entre l’application et son stockage, et protégez-le. S’il n’y en a pas, la créer est généralement le premier projet le moins coûteux.
Notre approche de ce type de travail est décrite sur les pages Modernisation des systèmes hérités et Migration et modernisation cloud.
Fait partie de la série Retours de nos projets. Recevez les nouvelles analyses par e-mail ou suivez le flux RSS.
Des normes appliquées de la même façon sur chaque mission, c’est ce qui permet à une petite équipe de développement de garder son rythme au-delà du premier mois. Voici ce que cela donne en pratique.
L’essentiel de notre travail consiste à construire des logiciels qui appartiennent à un client. UMOYA Zone est différent. C’est une coentreprise, et être copropriétaire d’un produit nous a appris des choses que le travail pour des clients n’enseigne pas.
Quand un investisseur regarde sous le capot d’une plateforme en croissance, les questions portent sur les identifiants, les données et la réalité des corrections. Ce que nous avons appris en menant une due diligence technique de la première revue jusqu’à la remédiation vérifiée.
