Début *2016*, les différents cantons suisses utilisaient le client lourd Kuba, l'application mère d'InfSuite. Ce logiciel était payé par l'#ref-glossary(term: "OFROU")[OFROU] pour une meilleure gestion des infrastructures routières en Suisse.
En *2019*, elle lance un appel d'offres dans le but de réduire les coûts liés aux applications qu'elle utilise. L'application Kuba étant une application hautement complète et complexe, le budget n'était alors pas forcément adapté à tous les cas d'usages des différents cantons, certains ayant des besoins différents en termes de gestion.
Unit Solutions a alors décidé de se lancer dans la conception d'une nouvelle solution nommée InfSuite, qui reprend le principe de l'application mère Kuba. La grande différence sur cette nouvelle application est le découpage plus fin des différentes fonctionnalités. Elle permet de proposer aux différents clients de ne leur octroyer l'accès à certaines fonctionnalités que s'ils en ont réellement besoin et permet ainsi de faire coller le budget au besoin.
Finalement adoptée par la suite par la majorité des cantons suisses, l'application InfSuite est une application géographique basée sur des technologies web récentes. Le but de l'application est de permettre de faire l'état et le suivi d'ouvrages d'art dans le temps. Lorsqu'un organisme responsable de la préservation des ouvrages d'art vient faire des constatations à une certaine date d'un ouvrage, il enregistre toutes les informations et données relatives dans l'application.
Lorsqu'une expertise ultérieure est réalisée sur l'ouvrage, de nouvelles observations seront ajoutées et avec ces nouvelles données l'application fournira un résumé de l'évolution de cet ouvrage, s'il a un comportement particulier, s'il faut planifier une intervention de conservation, etc.
Toutes ces données sont accessibles depuis n'importe quel terminal et depuis n'importe où tant que le client possède une connexion internet et un compte ayant les droits requis pour accéder aux données.
La suite logicielle InfSuite comprend plusieurs types d'outils, tous basés sur le même fonctionnement, mais avec des domaines d'application différents pour permettre d'effectuer des constatations plus spécifiques en fonction du domaine ciblé. Par exemple, sur l'outil InfAqua, il est possible de faire l'observation de cours d'eau (lit de rivières, berges...), InfRail des voies ferrées, InfVias de routes... Pour conserver la compréhensibilité de ce document, InfKuba sera l'outil de référence pour le fonctionnement technique de l'application.
L'application présente de manière simplifiée les données relatives aux différentes constatations sur une carte. Elle représente sous forme de pastilles colorées la note moyenne des ouvrages par zones géographiques lorsque plusieurs ouvrages se trouvent très proches les uns des autres comme le montre l'image @is-client-screen-1.
En fonction du niveau de zoom, les différents ouvrages se séparent les uns des autres et permettent de voir la dernière note calculée pour l'ouvrage sous forme d'une petite épingle qui représente l'objet d'infrastructure. La couleur varie du vert au rouge, indiquant respectivement que l'ouvrage est en bon état ou qu'il faut intervenir le plus rapidement possible, comme le montre l'image @is-client-screen-2.
En ouvrant les détails de l'objet, on peut retrouver un onglet regroupant les informations relatives à l'ouvrage d'art sous le même format que présenté @is-client-screen-3. On y retrouve des données basiques comme son nom, le canton propriétaire de l'ouvrage, ses dimensions, des commentaires, sa position géographique, des photos, etc.
#figure(
image("../assets/images/is-client-screen-2.png"),
caption: [Affichage individuel des ouvrages sur la carte]
)<is-client-screen-2>
#figure(
image("../assets/images/is-client-screen-3.png"),
caption: [Affichage des informations détaillées d'un ouvrage dans l'application]
D'autres onglets permettent de retrouver des informations plus précises telles que les observations de l'ouvrage, des graphiques sur l'évolution de l'ouvrage dans le temps, visualiser l'ouvrage en 3D (si fourni par le client)…
Chaque ouvrage appartient à un canton nommé dataowner, mais il peut être prêté à d'autres cantons, comme dans le cas où un pont serait partagé entre deux cantons par exemple. Un autre exemple d'ouvrage partagé est lorsque la gestion est déléguée à une ville plutôt qu'au canton. À ce moment, dans l'application, l'ouvrage appartient au canton et est « prêté » à la ville qui en est chargée. Chaque donnée générée à partir de l'application est rattachée au client qui en est à l'origine, ce qui permet d'avoir un historique en cas de problème. Pour permettre de rendre l'application plus légère, l'application est basée sur une architecture trois tiers.
Le premier tiers de l'application correspond à la base de données. Cette base de données est une base #ref-glossary(term: "PostgreSQL")[PostgreSQL]. C'est ici que toutes les données sont stockées ainsi que les relations entre chaque donnée existante. Je détaillerai les particularités techniques de cette base de données qui peuvent expliquer la pertinence de son utilisation dans ce contexte plus loin dans ce rapport.
Le second tiers de l'application correspond à l'#ref-glossary(term: "API")[API]. Une #ref-glossary(term: "API")[API] web est une interface de programmation qui permet à des applications informatiques de communiquer entre elles via Internet. Elle définit les règles et les formats de données pour faciliter l'échange d'informations entre les différentes applications.
Cette #ref-glossary(term: "API")[API] est le serveur #ref-glossary(term: "Back-End")[back-end] qui permet de faire la relation entre le monde extérieur et les données brutes stockées en base de données. Le serveur est développé en #ref-glossary(term: "C#")[C\#] avec l'#ref-glossary(term: "ORM")[ORM] #ref-glossary(term: "EF")[Entity Framework]. Cette interface permet notamment de mettre en forme les données pour qu'elles correspondent aux besoins du troisième et dernier tiers.
Le dernier tiers correspond à la partie visible de l'application. Appelé #ref-glossary(term:"Front-End")[Front-End], il met à disposition de manière visuelle et simplifiée les données. Ce dernier tiers permet également à l'utilisateur de créer, modifier ou effacer des données. Il est développé en TypeScript, un langage surrensemble de JS et avec le framework #ref-glossary(term: "Angular")[Angular] pour permettre de créer une application dynamique et réactive.
Le dernier service complémentaire est un serveur #ref-glossary(term: "GIS")[GIS]. Ce serveur permet de fournir des informations cartographiques comme des adresses. Il permet aussi de délivrer les fonds de cartes. Ils peuvent être hébergés et entretenus par Unit Solutions, ou alors par d'autres entreprises comme le fond de carte Open Street Map appartenant à la fondation du même nom. Il n'est pas intégré dans le concept d'architecture trois tiers puisque, comme je l'ai indiqué, ce service est indépendant et n'est pas une dépendance du reste.
Le schéma @three-tier-archi-diagram ci-dessous représente les trois tiers de l'application communicants ensemble. L'application propose à l'utilisateur de personnaliser toute l'application. Cela comprend par exemple quel fond de carte afficher, quelles données afficher, personnaliser l'affichage de ces données tel que le type d'affichage des épingles… Ces configurations sont propres à l'utilisateur et sont sauvegardées en base de données, en parallèle de toutes les autres données de l'application.
Ce document est axé sur le travail réalisé sur une base de données. L'application utilisant une base de données #ref-glossary(term: "PostgreSQL")[PostgreSQL], je présente dans cette section ce qu'est #ref-glossary(term: "PostgreSQL")[PostgreSQL], les avantages de cette technologie, les inconvénients et enfin une conclusion à cette section orientée.
#ref-glossary(term: "PostgreSQL")[PostgreSQL] est un système de gestion de base de données relationnelle (#ref-glossary(term: "SGBDR")[SGBDR]). Le projet est initié en 1986 par Michael Stonebraker et Andrew Yu à l'Université de Californie à Berkeley.
L'une des forces majeures de ce système est d'être Open Source, ce qui signifie qu'il est développé et maintenu par la communauté en plus des développements apportés par la société mère #ref-glossary(term: "PostgreSQL")[PostgreSQL].@administration-base-postgresql
#ref-glossary(term: "PostgreSQL")[PostgreSQL] tient sa réputation de sa fiabilité, sa robustesse et sa richesse fonctionnelle que je détaillerai juste après.
Comme dit précédemment, #ref-glossary(term: "PostgreSQL")[PostgreSQL] est un #ref-glossary(term: "SGBDR")[SGBDR]. Il utilise le langage SQL (Structured Query Language) pour chercher ou manipuler les données stockées. Le système met à disposition une série de fonctions pour permettre ces interactions, à savoir:
#ref-glossary(term: "PostgreSQL")[PostgreSQL] a également l'avantage d'être multiplateforme. Il peut ainsi fonctionner sur des environnements variés avec des systèmes d'exploitation différents, comme Windows, Linux, Mac, etc. L'une des forces de ce système de gestion de base de données réside dans sa capacité à gérer des volumes importants de données allant jusqu'à plusieurs Téraoctets@perf-analysis-pgsql. Cette gestion passe par différents points clés, à savoir:
- Il est open source, ce qui signifie qu'il est gratuit et que son code source est disponible pour tous. Cela permet à la communauté de développeurs de contribuer à son amélioration et de créer des extensions pour ajouter des fonctionnalités supplémentaires.
- Il est très fiable et robuste, ce qui en fait un choix idéal pour les applications critiques et les environnements de production.
- Comme vu précédemment, il est très performant, grâce à son moteur de stockage et son optimiseur de requêtes. Il est capable de gérer de gros volumes de données et de supporter des charges de travail élevées.
- Le système au complet est très flexible, grâce à son architecture modulaire et à son support des extensions. Il peut s'adapter à de nombreux types d'applications et de besoins, notamment pour des applications géographiques avec des besoins plus complets.
- Par sa nature open source, il est compatible avec de nombreux langages de programmation, tels que Python, Java, C++, Ruby, PHP, etc.
Il est également important de noter que #ref-glossary(term: "PostgreSQL")[PostgreSQL] tient sa popularité, au-delà de ses performances et fonctionnalités déjà complètes, grâce à sa capacité à gérer des types de données bien plus complexes. Il propose la gestion de modèles de données complexes tels que des données géographiques et des données attributaires, mais permet surtout de gérer les relations entre ces données.
Cette gestion de données complexe permet une ouverture sur d'autres systèmes, particulièrement QGIS, un système d'informations géographiques, et ainsi d'étendre les fonctionnalités proposées par ce système.
En type de fichiers volumineux, on peut par exemple citer les fichiers MAJICS, RPG, référentiels vecteurs, etc.
- Il peut être plus complexe à installer et à configurer que d'autres #ref-glossary(term: "SGBDR")[SGBDR], tels que MySQL ou SQLite.
- Il peut nécessiter plus de ressources matérielles (mémoire, CPU, espace disque) que d'autres #ref-glossary(term: "SGBDR")[SGBDR] pour fonctionner de manière optimale.
- Il peut être moins performant que d'autres #ref-glossary(term: "SGBDR")[SGBDR] pour certaines tâches spécifiques, telles que les requêtes de type OLAP (Online Analytical Processing).
#ref-glossary(term: "PostgreSQL")[PostgreSQL] est un #ref-glossary(term: "SGBDR")[SGBDR] open source très populaire, grâce à sa fiabilité, sa robustesse, sa richesse fonctionnelle et sa flexibilité. Il est utilisé dans de nombreux domaines, tels que la finance, la santé, l'éducation, le gouvernement, etc. Il est également compatible avec de nombreux langages de programmation et de nombreux systèmes d'exploitation.\
Cependant, il peut être plus complexe à installer et à configurer que d'autres SGBDR et nécessiter plus de ressources matérielles.\
Malgré ces inconvénients, #ref-glossary(term: "PostgreSQL")[PostgreSQL] reste un choix idéal pour de nombreuses applications critiques et environnements complexes grâce aux différents avantages cités précédemment, tel que sa rapidité, sa fiabilité et son aspect open-source.
L'application InfSuite s'appuie sur de nombreuses technologies développées en externe de l'entreprise pour fonctionner. Je peux par exemple citer Angular, un framework #ref-glossary(term: "Front-End")[front-end] développé par Google, qui est régulièrement mis à jour avec des réparations de bugs, des ajouts de nouveautés... et qui est utilisé dans l'application. Ce framework est continuellement mis à jour sans préavis pour les utilisateurs, mais utilise un système de versionnement. Le versionnement permet d'éviter les changements trop fréquents et perturbateurs, tout en offrant la possibilité d'introduire des améliorations et des nouvelles fonctionnalités de manière contrôlée. Il aide également les développeurs à anticiper les changements majeurs et à maintenir leurs applications à jour avec les dernières versions d'Angular.
Par exemple, dans le cas où Google déploierait des changements de code majeurs qui rendent le code ultérieur obsolète, le système de versionnement lui permet de rendre sa mise à jour accessible au grand public, sans pour autant forcer la main aux développeurs à effectuer une mise à jour qui pourrait mettre le fonctionnement de leur application en péril.
La majorité des technologies utilisées par InfSuite suivent ce système de versionnement. Malheureusement, réaliser de nouveaux développements pour l'application tout en surveillant les mises à jour des composants externes, analyser leur impact, les intégrer à l'application dès que ces dernières sont disponibles, n'est clairement pas possible. La stratégie de mises à jour utilisée est donc d'effectuer occasionnellement ces mises à jour, soit lors de moments clés (de nouvelles fonctionnalités importantes, des mises à jour de sécurité, des gains de performances, etc.), soit spontanément pour maintenir l'environnement à jour.
Ce cas de figure est présent à toutes les couches de l'architecture logicielle d'InfSuite, front-end, back-end, bases de données. Depuis un certain temps, l'application InfSuite utilise la version 14 du #ref-glossary(term: "SGBDR")[SGBDR] #ref-glossary(term: "PostgreSQL")[PostgreSQL]. Sortie en septembre 2021, cette version est maintenant dépréciée en faveur de la dernière version stable de l'application 16. Cependant, la version 14 a été adoptée très tôt par InfSuite et est restée depuis la version utilisée dans l'environnement InfSuite.
Pour suivre la stratégie de mise à jour de l'application, le sujet d'une mise à jour de la base de données d'InfSuite, de la version 14 vers la version stable la plus récente, a été mis sur la table. Le chef de projet en charge d'InfSuite a alors demandé une expertise pour la réalisation de cette migration pour s'assurer de la viabilité, mais également d'envisager, si possible, de réaliser cette migration en utilisant les nouveautés disponibles pour cette migration.
Je vais donc chercher à savoir quelles sont les étapes préliminaires pour s'assurer de la viabilité d'une telle migration, comment réaliser cette migration de manière optimale dans le contexte d'InfSuite et comment s'assurer de la qualité de la réalisation de cette dernière.
Effectuer une migration de base de données n'est pas une tâche anodine. Cela demande du travail en amont, il faut analyser les différents scénarios possibles, estimer un budget pour une telle tâche, réaliser de potentiels développements, s'assurer de la fiabilité avant de mettre tout cela en pratique et enfin la réalisation de l'étape cruciale sur les environnements sensibles.
Pour faire une migration de base de données, il existe de nombreuses solutions, certaines plus coûteuses, d'autres plus fiables, encore d'autres plus spécialisées, etc. Il faut donc dans un premier temps trouver différents outils pour comparer les avantages et leurs faiblesses.
On peut dans un premier temps penser à effectuer cette migration grâce à des outils spécialisés qui se chargent de faire la migration automatiquement et de s'assurer de la pérennité entre les données de l'ancienne base et les données insérées dans la nouvelle.
En prenant pour exemple l'outil Oracle Data #ref-glossary(term: "Dump")[Dump] fourni par l'entreprise Oracle, ce logiciel permet de sauvegarder et restaurer des données et des métadonnées pour les bases Oracle.
Il est rapide et fiable, on peut ainsi lui fournir un fichier #ref-glossary(term: "Dump")[Dump] de la base source et l'outil va se charger, grâce à ce fichier, d'intégrer les données dans la base cible.
Microsoft propose sa solution alternative SSMA pour importer les types de bases Access, DB2, MySQL, Oracle, SAP ASE vers leurs différents #ref-glossary(term: "SGBDR")[SGBDR] propriétaires (à savoir les suites SQL Server).
Sur le même principe, les outils MySQL Workbench, AWS Database Migration Service (DMS) et PgAdmin permettent de réaliser le même type de migration vers leurs systèmes propriétaires, à savoir respectivement MySQL, AWS et #ref-glossary(term: "PostgreSQL")[PostgreSQL].
- L'import des données reste assez strict et ne permet pas de flexibilité. Si les données ne sont pas compatibles, il faut passer du temps à travailler le modèle de données pour essayer de pallier aux incompatibilités.
- Ils peuvent également rendre les migrations onéreuses avec certaines solutions qui coûtent jusqu'à plusieurs centaines d'euros pour les entreprises.
- Les logiciels proposés peuvent parfois être complexes et demander un certain temps d'adaptation avant de réellement pouvoir effectuer la tâche de migration.
Il est possible, comme vu précédemment, d'effectuer une migration *à partir d'outils automatiques*. L'avantage est de déléguer la majorité de la complexité à une application qui va se charger d'effectuer la tâche cruciale et de réduire les risques d'erreurs pour de grosses applications. On retrouve en général des outils plus poussés pour offrir une plus grande précision et une meilleure cohérence dans la migration des données.
Il faut principalement noter, pour ce genre d'outils, qu'ils sont en général destinés à un certain type de base précis et qu'ils peuvent donc manquer de compatibilité. Ils peuvent également ne pas prendre en charge tous les types de bases de données ou tous les scénarios de migration, ce qui peut limiter leur utilité dans certains cas.
Enfin, le coût réel de ces outils peut être élevé, autant par leur prix réel fixé par l'éditeur, mais aussi parce que la majorité du temps, ils nécessitent une expertise pour être pris en main avant de pouvoir être réellement utilisés.
Une alternative à prendre en compte est la migration *manuelle*. Cette solution est intéressante pour les petites bases de données sans trop de complexité. Le but est d'exporter un fichier #ref-glossary(term: "Dump")[dump] de la base source et de l'importer dans la base cible si possible, ou d'exporter les données sous un autre format pour l'importer simplement. Les coûts de cette technique sont faibles, voire nuls et permettent une flexibilité lors de la migration. Cependant, le temps de migration peut se révéler très long, apporte un gros facteur de risque d'erreurs et devient complexe, voire inapproprié dans le cadre de bases avec de gros volumes.
Une autre technique consiste à effectuer la migration *via des scripts*. Le but est de développer un processus qui va récupérer les données de la base source, effectuer si besoin des opérations sur les différentes données pour les copier dans la base cible par la suite.
Quasiment tous les langages de programmation permettent de créer des scripts pour effectuer ce genre de migration, il suffit qu'un driver pour les bases utilisées soit disponible pour le langage souhaité.
L'avantage de ce type de migration réside dans la flexibilité totale pour personnaliser le processus de migration. Il est également possible de migrer des bases de données plus grandes et plus complexes avec des incompatibilités entre elles, puisqu'il est possible d'agir sur les données avant de les transférer vers la nouvelle base, ce qui confère un contrôle total sur la migration.
Cependant, il faut noter que les coûts de la migration peuvent aussi devenir élevés parce qu'il faut développer un script, donc payer un développeur. Il faut aussi prendre en compte que le temps de migration peut être long puisqu'il faut développer la solution en amont et qu'il faut en général s'assurer de la qualité du code avant de l'utiliser sur les environnements sensibles.
Même en essayant de prévenir les différents cas d'erreurs possibles, il se peut que certaines arrivent à se glisser, dans ce cas, le risque d'erreur humaine n'est pas négligeable.
Enfin, une solution peut se porter sur *la migration en temps réel*. La migration en temps réel est une technique qui permet de répliquer les données de la base source vers la base cible en temps réel, sans interrompre les opérations sur la base source. Elle est souvent utilisée pour minimiser le temps d'arrêt lors de la migration de bases de données critiques (secteur de la santé, du commerce, de la sécurité, etc.).
Ce processus de migration en temps réel implique les mêmes coûts qu'une migration par script ou par outils automatiques puisqu'elle va se reposer sur l'un de ces deux piliers. Elle va cependant permettre de minimiser l'impact sur le service actif parce qu'elle ne requiert généralement pas de mettre le service à l'arrêt.
Il faut cependant noter que lors de la migration, l'impact des erreurs pouvant se glisser durant le processus de migration deviendrait rapidement beaucoup plus important, car les données sont consommées à l'instant où elles sont migrées.
La migration en temps réel n'est donc réellement intéressante que dans le cas où la relation entre une application qui ne peut pas avoir de temps d'inactivité avec les données de la base est critique.
Il existe de nombreux outils pour effectuer des migrations de données à partir de bases de données. Cependant, il faut prendre en compte différents critères, comme la complexité de la migration, le budget alloué, les systèmes source et cibles, mais aussi la stratégie à appliquer lors de cette étape. Par exemple, dans un cas, le temps alloué à la migration peut être ignoré si ce qui compte est d'effectuer la migration sans arrêter le service, dans un autre cas, le temps d'arrêt est moins important que la fiabilité de la migration.
Il faut donc réfléchir en amont à la manière d'effectuer cette étape, mais surtout à la pertinence de cette tâche pour éviter des coûts supplémentaires qui pourraient se révéler inutiles.
Toutes ces questions permettent de cibler le besoin et donc le type de migration souhaité pour, par la suite, transférer ses données entre deux systèmes.
