Migration des charges de travail en 2026 : Guide stratégique pour les entreprises qui abandonnent les infrastructures existantes

Remarque : Ce contenu a été généré par traduction automatique et peut contenir des inexactitudes. Pour obtenir les informations les plus précises et les plus récentes, veuillez consulter la version originale en anglais.

L'infrastructure des entreprises entre dans une période de transformation profonde, et les entreprises doivent s'adapter sous peine d'être dépassées. Avec la restructuration des licences VMware, la hausse des coûts d'infrastructure et le retour aux clouds publics, sans oublier les cycles de renouvellement du matériel et les besoins croissants en IA, de plus en plus d'organisations sont contraintes de repenser l'emplacement et la gestion de leurs charges de travail. Pour beaucoup d'entreprises, 2026 s'annonce comme une année charnière pour les décisions d'infrastructure qui façonneront leurs opérations informatiques pour les années à venir.

Cependant, le défi ne se résume pas à déplacer des machines virtuelles d'un environnement à un autre. Chaque charge de travail présente des exigences de performance, des dépendances, des considérations de sécurité et des conséquences opérationnelles différentes en cas de problème. Un plan de migration basé uniquement sur une liste de contrôle technique peut rapidement compromettre la continuité des activités si les applications perdent leur connectivité, si les sauvegardes échouent ou si les utilisateurs subissent une interruption de service inattendue. C'est pourquoi la migration des charges de travail doit être considérée comme une décision stratégique, et non comme un simple projet technique.

Aujourd'hui, les organisations qui réagissent aux pressions immédiates sur les coûts sans évaluer leurs besoins d'infrastructure globaux risquent de simplement remplacer un ensemble de difficultés opérationnelles par un autre. Prenons l'exemple de la migration de machines virtuelles et de la migration de charges de travail. Alors que la migration de machines virtuelles consiste à déplacer une machine virtuelle entre hôtes, centres de données ou plateformes, la migration de charges de travail adopte une perspective plus large : elle s'intéresse à la pertinence même du déplacement de l'application, à l'environnement le plus adapté et aux modifications nécessaires à son bon fonctionnement ultérieur.

Pour certaines charges de travail, rester sur une plateforme existante demeure la meilleure option. Cependant, d'autres peuvent tirer profit d'un hyperviseur alternatif, d'un cloud privé, d'un cloud public ou d'une infrastructure hyperconvergée (HCI) moderne. L'objectif n'est pas de tout migrer, mais de faire des choix éclairés en fonction de la valeur ajoutée pour l'entreprise. Ce guide explore les facteurs qui influenceront la migration des charges de travail en 2026, propose un cadre pratique pour déterminer leur emplacement optimal, met en lumière les risques liés à la migration des charges de travail VMware et explique comment les entreprises peuvent moderniser leur infrastructure tout en préservant la stabilité opérationnelle. Commençons donc par aborder quelques concepts fondamentaux.

Qu'est-ce que la migration de charge de travail ?

La migration de charge de travail consiste à déplacer une application et ses ressources associées d'un environnement d'infrastructure à un autre, tout en préservant les fonctionnalités, la sécurité et les niveaux de service requis. Ces ressources comprennent généralement les capacités de calcul, de stockage, de réseau, les systèmes d'exploitation, les configurations applicatives, les services d'identité et les solutions de sauvegarde. Selon l'application, elles peuvent également inclure les bases de données, les intergiciels, les intégrations et les services externes.

Par conséquent, une charge de travail ne se résume pas à une simple machine virtuelle. Le simple fait de déplacer un serveur ne garantit pas le bon fonctionnement de l'application qui y est exécutée. Sa base de données pourrait rester inaccessible, ses règles de pare-feu pourraient ne pas être transférées, ou ses tâches de sauvegarde planifiées pourraient ne plus fonctionner. En revanche, une migration d'application efficace prend en compte ces dépendances bien avant le début du déplacement. Il existe généralement trois principales approches de migration de charges de travail, auxquelles s'ajoute une quatrième option pour les applications qui n'ont plus besoin d'être migrées : leur mise hors service ou leur remplacement.

1. Migration « lift-and-shift » : Déplacement d’une charge de travail existante vers un nouvel environnement avec un minimum de modifications, accélérant la migration lorsque l’application est stable et bien maîtrisée. Cette méthode peut toutefois perpétuer les inefficacités existantes sur la plateforme cible.
2. Migration de plateforme : Apporter des modifications ciblées pour exploiter les capacités de l’environnement de destination. Par exemple, une entreprise peut déplacer une machine virtuelle de base de données vers un nouvel environnement et adopter un service de base de données managé, ou adapter la configuration de stockage et de ressources de l’application pour tirer parti de la plateforme cible. Le déplacement d’une machine virtuelle de VMware vers un autre hyperviseur avec un minimum de modifications est généralement appelé « lift-and-shift ».
3. Réarchitecture : Repenser une application pour un environnement différent, comme les conteneurs, les microservices ou les services natifs du cloud. Cette approche peut offrir une plus grande flexibilité à long terme, mais elle exige généralement plus de temps, de tests, d’investissement et d’expertise applicative.

En définitive, la meilleure stratégie de migration de charges de travail est celle qui tient compte de l'importance métier, de l'état technique et des besoins futurs de l'application. Toutes les applications existantes ne nécessitent pas une refonte complète, et certaines ne doivent pas être migrées sans modification. Voyons maintenant pourquoi la migration de charges de travail est aujourd'hui au cœur des préoccupations.

Le paysage de la migration des charges de travail en 2026 : quels sont les facteurs qui la motivent ?

Aujourd'hui, de nombreuses forces de marché transforment la manière dont les entreprises gèrent le déploiement des charges de travail. Chacune d'elles induit un changement significatif des pratiques et des mentalités au sein du secteur. Comprendre ces facteurs est essentiel pour saisir pourquoi la migration des charges de travail doit être une priorité pour les entreprises.

Restructuration des licences VMware

L'acquisition de VMware par Broadcom a profondément modifié le portefeuille de produits et le modèle de licences de l'entreprise, notamment en faisant passer les licences perpétuelles aux abonnements. Cette évolution a incité de nombreuses organisations à réévaluer leurs engagements de renouvellement, leurs coûts d'infrastructure et leur dépendance à long terme à un écosystème de virtualisation unique. Pour beaucoup d'entre elles, la hausse des coûts de renouvellement de VMware a catalysé une stratégie de migration des charges de travail plus globale, les amenant à réévaluer quelles charges de travail doivent rester sur VMware, lesquelles doivent migrer vers des hyperviseurs alternatifs comme Sangfor HCI, et lesquelles doivent être transférées vers le cloud.

Rapatriement du cloud

Le cloud public demeure essentiel pour de nombreuses organisations, mais son adoption a également mis en lumière l'importance d'adapter les coûts d'infrastructure au comportement des charges de travail. De ce fait, de nombreuses organisations migrent leurs charges de travail des clouds publics vers des infrastructures privées. Selon l'étude « Private Cloud Outlook 2026 » de Broadcom , près de 83 % des entreprises envisagent désormais de rapatrier leurs charges de travail vers des clouds privés. Cela concerne particulièrement les charges de travail dont la demande est prévisible, qui nécessitent d'importants transferts de données, une faible latence ou qui sont soumises à des obligations spécifiques de résidence des données. À l'inverse, les applications dont la demande est très variable ou qui dépendent fortement des services cloud managés peuvent rester plus adaptées au cloud public.

Besoins en infrastructure d'IA

L'essor de l'IA complexifie la migration des charges de travail. L'inférence, le développement de modèles, l'analyse et la préparation des données engendrent de nouvelles exigences en matière de calcul, de stockage et de réseau. Selon IDC , les dépenses mondiales en infrastructures d'IA ont atteint 318 milliards de dollars en 2025 et devraient atteindre 487 milliards de dollars en 2026, illustrant ainsi l'ampleur des investissements qui redéfinissent la planification des infrastructures.

Pour certaines entreprises, une plateforme HCI moderne ou une plateforme de cloud privé avec prise en charge GPU, stockage NVMe et réseau à large bande passante peut constituer une base pratique pour les charges de travail d'IA, bien que la conception appropriée dépende de la taille du modèle, de l'emplacement des données et des exigences de performance.

Fin de vie du matériel

De nombreux serveurs acquis entre le milieu et la fin des années 2010 ont désormais atteint, voire dépassé, leur date de garantie constructeur ou de fin de support, ce qui engendre une nécessité de renouveler le matériel tout en assurant la disponibilité des applications. La migration vers une infrastructure de remplacement est l'occasion de repenser la virtualisation, le stockage, l'architecture réseau et le plan de reprise d'activité.

L'approche pratique pour la migration des charges de travail consiste à coordonner les initiatives de chaque méthode tout en maîtrisant leur portée. Il faut commencer par valider la plateforme cible, vérifier la compatibilité matérielle, puis migrer les charges de travail par étapes. Pour une description plus détaillée, examinons comment déterminer la destination de chaque charge de travail.

Cadre décisionnel de migration des charges de travail : Où chaque charge de travail doit-elle être déplacée ?

En définitive, la stratégie de migration de charge de travail la plus efficace considère chaque application comme une décision métier individuelle s'inscrivant dans un plan d'infrastructure global. Le cadre en quatre étapes suivant aidera les équipes techniques et les dirigeants à prendre ces décisions de manière cohérente et efficace.

Étape 1 : Classer les charges de travail par profil de migration

Votre plan de migration nécessite des bases solides, ce qui passe nécessairement par une bonne compréhension du rôle de chaque charge de travail et de ses possibilités d'optimisation. Commencez par évaluer chaque charge de travail selon ces quatre critères :

Cette évaluation devrait inclure les responsables d'applications, les équipes d'infrastructure, les spécialistes de la sécurité et les représentants financiers. Les équipes techniques comprennent les dépendances, tandis que les parties prenantes métiers précisent le coût des interruptions de service et les conséquences d'une modification du comportement des applications.

Étape 2 : Faire correspondre les charges de travail au modèle de migration approprié

Une fois vos charges de travail classées, sélectionnez une approche de migration appropriée.

Migration « lift-and-shift » : Idéale pour les charges de travail stables, compatibles avec la plateforme cible et nécessitant une migration avec un minimum de modifications applicatives. Elle peut raccourcir les délais de migration, mais les performances et l’allocation des ressources doivent tout de même être validées.

Replatforming : Idéal lorsque des modifications ciblées peuvent améliorer l’utilisation de l’infrastructure de destination par une charge de travail. Par exemple, une machine virtuelle VMware migrée vers Sangfor HCI peut bénéficier de politiques de stockage aSAN correctement configurées et d’une allocation de ressources révisée, sous réserve de compatibilité et de validation de la charge de travail.

Refonte architecturale : utile lorsque la conception existante limite l’évolutivité, la maintenabilité ou l’agilité de l’entreprise. La conteneurisation ou la refonte de l’application peuvent se justifier, mais elles doivent reposer sur une analyse de rentabilité claire et ne pas constituer une exigence par défaut pour chaque migration.

Mise hors service ou remplacement : Idéal pour les applications redondantes, obsolètes ou de faible valeur qui peuvent être mises hors service ou remplacées en toute sécurité par un service SaaS approprié.

Étape 3 : Séquencer les migrations en fonction du risque

Pour éviter de migrer toutes les charges de travail simultanément et de perturber les flux de travail, commencez par un groupe pilote d'applications peu complexes afin de tester vos outils de migration, vos procédures opérationnelles, la configuration de votre réseau et l'intégration de vos sauvegardes. Tirez profit de cette expérience pour affiner le processus avant de migrer des applications plus exigeantes.

Essayez de regrouper les phases successives par dépendances applicatives, fonctions métier, fenêtres de maintenance et exigences de restauration. Pour les grandes entreprises, le programme peut s'étendre sur plusieurs trimestres, voire plusieurs années. Un horizon de planification de 12 à 36 mois constitue un point de départ utile pour un parc informatique important, mais le calendrier précis dépendra du volume de travail, des échéances contractuelles, du personnel disponible et de la complexité des applications.

Étape 4 : Définir le succès avant toute action

La migration de la charge de travail n'est pas réussie du seul fait que sa machine virtuelle démarre sur l'hyperviseur de destination. Il est nécessaire de définir au préalable des critères d'acceptation mesurables. Ceux-ci peuvent inclure :

• Temps de réponse de l'application et utilisation des ressources comparés aux valeurs de référence établies.
• Disponibilité, objectifs de temps de récupération (RTO) et objectifs de point de récupération (RPO).
• Tests de sauvegarde et de restauration réussis sur la plateforme de destination.
• Connectivité réseau, intégration des identités, contrôles d'accès et surveillance de la sécurité.
• Approbation du propriétaire de l'application et validation par l'utilisateur final.
• Un point de décision et un processus de retour en arrière documentés.

Cette dernière étape transforme la migration des charges de travail, d'une série de modifications d'infrastructure, en une transformation métier maîtrisée. Intéressons-nous maintenant à la raison pour laquelle la migration VMware est devenue un élément si crucial en 2026.

Migration des charges de travail VMware : la priorité des entreprises en 2026

Pour les entreprises disposant d'un parc VMware important, la migration s'apparente souvent à un programme global plutôt qu'à une simple opération technique. Une organisation exploitant des centaines, voire des milliers de machines virtuelles, doit gérer simultanément le choix de la plateforme, les dépendances, les tests, les licences, la préparation organisationnelle et la continuité de service. Il est donc essentiel de bien comprendre vos processus et les alternatives disponibles avant d'entamer une migration VMware.

Évaluez la destination avant de commencer la migration VMware.

Avant de vous engager dans le remplacement de VMware, évaluez quatre domaines :

• Compatibilité de la charge de travail : L’application et le système d’exploitation invité peuvent-ils fonctionner sur l’hyperviseur cible sans refonte majeure ? Testez la charge de travail réelle plutôt que de vous fier uniquement aux déclarations de compatibilité générales.
• Maîtrise opérationnelle : L’équipe infrastructure est-elle capable de gérer efficacement le provisionnement, la surveillance, le dépannage, la sécurité et la reprise après sinistre ? Envisagez des formations et des modifications des procédures opérationnelles.
• Coût total de possession : Comparez les coûts sur trois à cinq ans, y compris les licences, le support, le matériel, les services de migration, la formation continue, la sauvegarde, la reprise après sinistre et l'administration courante.
• Maturité de l'écosystème : Vérifier l'intégration avec les outils de sauvegarde, de surveillance, de sécurité, d'automatisation et de reprise après sinistre. Confirmer la prise en charge des versions exactes et des configurations de déploiement concernées.

Cette évaluation doit impliquer les parties prenantes tant commerciales que techniques. Une plateforme qui semble attractive du seul point de vue des coûts de licence peut ne pas offrir les meilleurs résultats si elle nécessite une formation approfondie ou introduit des dépendances non prises en charge.

Considérations techniques clés lors de la migration depuis VMware

Votre entreprise doit également évaluer plusieurs éléments techniques avant de lancer sa campagne de migration VMware. Il s'agit notamment des éléments suivants :

• Conversion du format de disque : les machines virtuelles VMware utilisent généralement des fichiers de disque virtuel VMDK. La migration vers un autre hyperviseur peut nécessiter une conversion ou une importation dans un format de disque compatible. Vérifiez les formats acceptés par la plateforme cible et assurez-vous que l’outil de migration sélectionné effectue bien la conversion.
• Outils et pilotes invités : VMware Tools assure l’intégration et la gestion du système d’exploitation invité. Selon la plateforme et le système d’exploitation cibles, il peut être nécessaire de supprimer ou de remplacer VMware Tools par des agents et pilotes invités compatibles. Planifiez soigneusement cette opération, notamment pour les systèmes dotés de configurations réseau ou de stockage spécifiques.
• Reconstruction du réseau : les commutateurs virtuels, les paramètres de commutation distribuée, les VLAN, les règles de pare-feu et les configurations dépendantes de NSX ne peuvent être transférés tels quels vers une autre plateforme. Il est impératif de cartographier l’architecture du réseau source, de reproduire les contrôles nécessaires sur le réseau de destination et de tester la connectivité et la segmentation avant la mise en production.
• Continuité des sauvegardes : Les intégrations de sauvegarde conçues autour des API vSphere for Data Protection (VADP) de VMware peuvent ne pas protéger les charges de travail après leur migration hors de VMware. Il est impératif d’établir et de tester la couverture de sauvegarde sur la destination avant la mise hors service de l’environnement source. Vérifiez les politiques de rétention, les procédures de restauration et la compatibilité avec la reprise après sinistre.
• Dépendances et restauration des applications : documentez les connexions aux bases de données, aux systèmes d’authentification, aux services externes et aux tâches planifiées. Pour chaque phase de migration, définissez comment l’équipe identifiera les pannes, rétablira le service et décidera de poursuivre ou d’annuler la migration.

Gestion des programmes de remplacement de VMware à grande échelle

Dans le cadre d'infrastructures d'entreprise complexes, une approche par étapes est essentielle pour prévenir la latence, les interruptions de flux de travail et autres problèmes. Chaque phase doit définir un périmètre de charge de travail précis, des responsables désignés, une fenêtre de changement, des critères d'acceptation et une procédure d'escalade. Il est important de maintenir les charges de travail sources disponibles jusqu'à ce que l'application cible ait passé ses tests d'acceptation et que la période de restauration soit terminée, dans la mesure où l'architecture et les exigences opérationnelles le permettent.

Il est également essentiel que vos systèmes source et de destination ne fonctionnent pas simultanément, afin d'éviter les transactions dupliquées ou les incohérences de données. Bien que les échéances de licence VMware puissent vous inciter à accélérer le processus, un calendrier serré n'est utile que si l'environnement de destination, les équipes, les outils et les processus de reprise sont prêts. L'objectif principal n'est pas simplement de quitter VMware, mais de mettre en place un modèle d'infrastructure capable de répondre aux besoins futurs de l'entreprise, avec un niveau de coût, de complexité et de risque acceptable. Voyons donc comment Sangfor peut vous aider à optimiser vos plans de migration de flux de travail.

Comment Sangfor prend en charge la migration des charges de travail d'entreprise

Sangfor Technologies est un fournisseur multinational mondial de solutions d'infrastructure cloud et de cybersécurité basées sur l'IA, au service des moyennes et grandes entreprises en Asie-Pacifique, au Moyen-Orient, en Europe et en Amérique latine. Sangfor propose une plateforme HCI complète ainsi qu'un hyperviseur autonome, offrant ainsi aux organisations évaluant les alternatives à VMware une grande flexibilité dans leur modernisation.

Pour les entreprises souhaitant remplacer VMware, l'infrastructure hyperconvergée (HCI) de Sangfor réunit les capacités de calcul, de stockage, de réseau et de sécurité au sein d'une plateforme intégrée. Son architecture permet aux organisations d'évaluer la modernisation de leur infrastructure dans le cadre d'une stratégie globale de migration des charges de travail, plutôt que de considérer le calcul, le stockage et le réseau comme des projets totalement distincts.

Sangfor a bien compris que le point de départ idéal est une évaluation de la charge de travail permettant de déterminer quelles applications sont adaptées à la migration, quelles dépendances nécessitent une attention particulière et quelles sont les exigences de l'environnement cible. Voyons donc comment Sangfor optimise la migration des charges de travail à grande échelle :

Sangfor HCI : une destination de migration intégrée

Sangfor HCI combine plusieurs fonctionnalités d'infrastructure, notamment la virtualisation de calcul aSV, qui fournit l'hyperviseur nécessaire à l'exécution des charges de travail virtualisées. Sangfor aSAN est une couche de stockage logicielle distribuée et entièrement intégrée, permettant de planifier la capacité de stockage, les performances et la résilience conjointement avec les ressources de calcul lors de la migration. Sangfor aNET offre une virtualisation réseau intégrée avec une gestion visuelle, tandis qu'aSEC renforce la sécurité des charges de travail virtualisées.

La plateforme cloud de Sangfor assure la gestion centralisée de l'environnement virtualisé, offrant aux administrateurs une interface unique pour le provisionnement, la surveillance et l'exploitation, comparable à VMware vCenter Server. Ensemble, ces composants permettent aux entreprises d'évaluer la consolidation des charges de travail et la modernisation de leur infrastructure. L'analyse de rentabilité doit reposer sur la compatibilité validée des charges de travail, les exigences opérationnelles, la résilience et les coûts du cycle de vie, et non sur l'hypothèse que toutes les applications bénéficieront de la même manière d'une destination unique.

Compatibilité de Sangfor avec l'écosystème VMware

Lors de l'évaluation des solutions d'entreprise, il est essentiel de comparer les fonctionnalités équivalentes afin de choisir l'alternative idéale à VMware. Heureusement, Sangfor aSV prend en charge la migration des machines virtuelles VMware, y compris les systèmes d'exploitation invités courants, ce qui peut limiter les besoins de réarchitecture. La compatibilité doit toutefois être validée pour chaque charge de travail, version de système d'exploitation invité et configuration. L'aSV est également disponible en tant qu'hyperviseur autonome pour les entreprises souhaitant migrer leurs ressources de calcul avant d'adopter pleinement l'infrastructure hyperconvergée (HCI).

Outils et exécution de la migration

Les outils de migration de charges de travail permettent de réduire les interventions manuelles, mais leurs fonctionnalités varient selon la plateforme source, la version cible, le système d'exploitation invité et la méthode de migration. Sangfor propose des outils de migration qui automatisent les étapes clés des migrations VMware vers aSV, telles que la conversion du format de disque et le remplacement des outils invités. Il est toutefois indispensable de vérifier et de tester la configuration des politiques réseau et de sécurité avant la mise en service.

Protection des sauvegardes et des restaurations tout au long de la migration

La continuité des sauvegardes est essentielle à tout programme de remplacement de VMware. Une charge de travail fonctionnant correctement après la migration n'est pas pleinement opérationnelle en production si son nouvel environnement ne dispose pas d'une couverture de sauvegarde et de restauration testée. Grâce à ses partenariats au sein de son écosystème, Sangfor aide les entreprises à planifier la sauvegarde et la restauration dès le début d'une migration. Veeam prend en charge l'orchestration de la sauvegarde, de la restauration et de la reprise après sinistre pour les environnements Sangfor, tandis que Cohesity, suite à sa fusion avec Veritas, assure la résilience, la gestion et la sécurité des données. Les tâches de sauvegarde et les procédures de restauration doivent néanmoins être testées sur la plateforme cible avant la mise hors service de l'environnement source.

Gestion de la visibilité et de la gouvernance des migrations

Lors de la migration, SCP assure la gestion centralisée de l'environnement cible Sangfor HCI, notamment l'état des machines virtuelles et l'utilisation des ressources, tandis que les équipes continuent de surveiller l'environnement source VMware avec leurs outils existants. Lorsque les organisations exploitent simultanément des environnements VMware et Sangfor, la visibilité tout au long de la transition est primordiale.

L'organisation mondiale de services professionnels de Sangfor propose également des services de planification de migration, d'assistance à l'exécution par vagues et de validation post-migration pour les entreprises gérant d'importants programmes de remplacement de systèmes VMware, ainsi qu'un accompagnement régional et à l'échelle de l'entreprise pour les migrations complexes. En définitive, le partenaire d'infrastructure idéal est celui qui peut accompagner l'entreprise tout au long du cycle de vie de la migration : de l'évaluation et des tests à la mise en production, en passant par la validation de la reprise après sinistre et l'exploitation continue.

Conclusion

La migration des charges de travail en 2026 offre aux entreprises bien plus qu'un simple remplacement d'infrastructures vieillissantes ou une adaptation aux changements de licences VMware. C'est l'occasion de réévaluer les besoins applicatifs, d'optimiser le placement des charges de travail, de renforcer la résilience et de bâtir une stratégie d'infrastructure qui soutienne les priorités commerciales futures. L'enjeu principal est de prendre des décisions éclairées quant aux charges de travail à migrer, à leur emplacement d'exécution et à leur gestion post-migration.

Une stratégie de migration de charges de travail réussie repose sur une évaluation rigoureuse, une exécution progressive, une compatibilité validée et une continuité de service en matière de sauvegarde et de restauration. Que la destination soit un cloud public, un cloud privé ou une infrastructure hyperconvergée, chaque migration doit générer une valeur ajoutée mesurable sur les plans commercial et opérationnel.

Pour les entreprises qui recherchent des alternatives à VMware, Sangfor propose une solution de niveau entreprise pour moderniser leur infrastructure cloud. Avec aSV, aSAN, aNET, aSEC et une gestion centralisée via la plateforme Sangfor Cloud, Sangfor HCI offre une plateforme intégrée et performante aux organisations qui remplacent VMware et migrent vers un cloud privé ou hybride.

L’objectif n’est pas simplement de déplacer les charges de travail, mais de les installer sur des bases solides pour les étapes suivantes. Les entreprises qui abordent la migration de manière stratégique peuvent réduire la complexité inutile, améliorer la fiabilité opérationnelle et optimiser la flexibilité de leurs décisions en matière d’infrastructure.

FAQ