Refonte et transformation des sites

web de la Banque Africaine de

Développement
Note de compréhension et Méthodologie

Wisdom E.HOUEDE
Contexte
La Banque Africaine de Développement (BAD) lance un appel aux cabinets de conseil pour la refonte et la
transformation de ses sites Web, avec une attention particulière sur le site principal, afdb.org. Ce projet vise à
effectuer une refonte complète conformément au guide de style récemment introduit, mettant en avant la
modernisation des éléments de conception et de style.

Actuellement opérationnel sur une version 7.x de Drupal, le site subira une migration vers la dernière version
du système de gestion de contenu (CMS). Cette évolution s'accompagne d'une transformation globale,
alignant le site sur les recommandations d'un rapport d'audit récent. L'objectif ultime est d'apporter des
changements significatifs pour garantir que le site Web de la BAD atteigne les normes les plus élevées en
termes de performances, de sécurité et d'expérience utilisateur.

Ce présent document présente donc une note descriptive de notre compréhension de la mission ainsi que
l’approche méthodologique permettant d’atteindre les objectifs et de répondre aux besoins exprimés.
Description de la mission
Cette mission a pour objectif d’aboutir à la refonte des sites web de la Banque Africaine de Développement. L’on
distingue 3 catégories de sites qui sont :

- le site principale de la banque

- les autres sites
- l’intranet

Phase 1: Refonte du site web principal
de la banque
●Refonte visuel du site en Drupal 7
●Migration de la plateforme vers Drupal 10
●Refonte visuel en Drupal 10
Phase 2: Refonte des autres site de la
banque
●Migration des sites vers Drupal 10
●Refonte visuel des sites
●Mise en place d’un multisite
Phase 3: Refonte de l’intranet
●Migration de l’intranet vers
Drupal 10
●Refonte visuel des sites
Récapitulatif des actions
Notre intervention s’articule principalement autour de la Refonte visuelle, la Migration
du core fonctionnel vers Drupal 10, et la Mise en place d’un multisite.

L’ensemble de ces actions devra être effectué au cas par cas relativement à la plateforme
concernée et à l’environnement de cette dernière.
La refonte visuelle
Cette refonte visuelle s’articule autour des points suivants:

● Assurer l'alignement sur l'identité de la marque en respectant la charte graphique de la banque.

● Améliorer l'expérience utilisateur en ajustant la navigation, la mise en page et la convivialité du site
web.
● Garantir un design et un rendu responsive pour une adaptation optimale à divers écrans et appareils.
● Mettre en place une configuration multisite avec une base de code partagée et des fonctionnalités
de recherche multisite et monosite.
● Intégrer des outils d'intelligence artificielle pour améliorer le traitement du langage naturel, la
recherche et la récupération d'informations, y compris l'utilisation de chatbots, assistants virtuels,
bases de connaissances et analyses pour enrichir l'expérience utilisateur.
● Collaborer avec une agence d'accessibilité Web certifiée pour rendre tous les types de contenus
accessibles, y compris les pages HTML, documents PDF, vidéos, podcasts et images.
La refonte du core fonctionnel
Cette action se subdivise en plusieurs points :

● Une mise à jour du core de Drupal de la version 7 vers la version 10

● Prise en charge des recommandations de l’audit (sécuritaire - UI/UX)
● Migration des données
● Une optimisation du référencement SEO
● Intégrer une prise en charge multilingue pour (4) quatre langues (arabe, anglais, français, portuguais)
● Intégrer des médias sociaux, pour favoriser le partage de contenu
● Intégrer un outil de suivi et d’analyse du site web (google analytics)
● Mettre en place des call to action permettant aux utilisateurs de donner leurs avis et suggestions
La mise en place d’un multisite
Un multisite est une configuration où une seule installation de Drupal gère plusieurs sites web distincts au sein d'une
même infrastructure. Chaque site partage le même code source principal de Drupal, mais dispose de sa propre base
de données distincte, de ses fichiers de configuration spécifiques, et souvent de son propre nom de domaine.

Quelques caractéristiques d’un multisite :

● Partage de code source,

● Bases de données distinctes,
● Fichiers de configuration spécifiques à chaque site,
● Domaines multiples.
Méthodologie de réalisation du projet
Pour mener à bien ce projet, nous utiliserons le schéma directeur ci contre, pour
chacune des 3 phases de notre intervention.
Etude préalable

Architectures Définition des politiques Etude & analyse détaillée Design thinking
de sécurités

Découpage agile du Mise en place de Développement et

l’environnement de Tests et releases
projet Revue de code
travail

Recette Globale
Explication
Etude préalable

Phase d’étude du cahier de charges ou de l’expression de besoin transmis par le demandeur. Elle permettra d’orienter
les phases initiales telles que celle du Design Thinking.

Design thinking

Phase d’idéation permettant de faire ressortir la problématique mais à l’échelle humaine. Quels sont les profils
concernés par celle-ci (acteurs directs et indirects), avec leurs niveaux d’implications, et leur capacité d’interagir avec
la solution produite.
Au cours de cette phase, des ateliers sont réalisés avec des échantillons représentatifs des profils ciblés. Le but étant
de réaliser une solution affordante, et de faciliter la culture du changement.
Explication
Etude et analyse détaillées
En se basant sur les précédentes phases et les résultats obtenus, une étude d’ingénierie est réalisée afin de découper
le projet en briques fonctionnelles, faire ressortir les données pertinentes à prendre en compte et leur forme,
d’identifier les acteurs clés, les permissions à leur attribuer dans le projet, schématiser les interactions et processus.
Le choix des technologies sera également fait à cette phase. A titre d’exemple pour la gestion des données, il y aura un
mix entre bases de données relationnelles et bases de données non- relationnelles. Un système de cache peut
également être proposé afin d’optimiser les temps de réponses.

Définition des politiques de sécurité

Au cours de cette phase les choix sécuritaires seront faits, et devront être appliqués tout au long du projet. Ils seront
applicables à l’ensemble des niveaux de la chaine : adminsys, développeurs, testeurs, utilisateurs finaux.
Cette phase a également un impact sur le choix des technologies. Plus de détails dans le prochain grand titre.
Explication
Architectures et callflows

Les architectures fonctionnelles, synoptiques, réseaux etc. sont réalisées dans cette phase afin de permettre à chacun
des acteurs d’avoir une idée de l’environnement dans lequel évoluera le système.
Objectif, mettre en lumière les interactions entre les briques, et les technologies choisies, matérialiser les échanges
avec les infrastructures tierces...

Structuration et découpage agile

Le projet sera réalisé de façon agile. L’équipe de réalisation (core team), les parties prenantes seront initiées, si besoin
est, à ces principes. Le découpage sera fait par fonctionnalité qui seront embarquées en plusieurs phases (sprint) selon
la capacité d’absorption. A l’issue de chaque phase, une présentation sera faite aux parties prenantes en vue de
restitution, mais aussi recueil de leurs appréciations.
Explication
Mise en place des environnements de travail

L’architecture définie un peu plus haut sera matérialisée pour permettre aux acteurs de déployer leurs travaux, mais
aussi aux parties prenantes d’avoir des éléments palpables quant à la réalisation des travaux. Nous aurons idéalement
3 environnements: development, preproduction, production.
L’environnement des développeurs et adminsys est également concerné. Pour des questions d’interopérabilité et de
facilités, nous irons sur des environnements Docker, et avec des terminaux au spécifications iso à celles de production.
Le système de déploiement et intégration continu est également mis en place, afin de cloisonner les environnements,
et éviter le plus possible la survenue de régressions.

Revue de code

Avant chaque déploiement sur l’environnement de développement, le code réalisé et poussé sur le système de
versionning devra faire l’objet d’une revue afin de s’assurer qu’il respecte les normes définies pour le projet
(spécifiquement), et celles définies dans le fonctionnement global de la Banque. Objectif, produire du code facilement
maintenable, et éviter le plus possible les régressions
Explication
Tests et releases

A l’issue de la réalisation d’une fonctionnalité, des tests fonctionnels seront réalisés afin de garantir l’adéquation entre
le besoin et la réalisation. Lorsqu’un sprint est réalisé, une release est faite avec l’ensemble des fonctionnalités du
sprint, une documentation de réalisation et un cahier de tests.

Livraison du projet

A l’issue de finalisation de l’ensemble des sprints et des tests, la solution est déployée sur l’environnement de pré
production pour des tests dans des conditions réelles. Une fois que ces tests sont concluant la solution sera déployé
sur la plateforme de production. La phase de livraison du projet s’accompagne aussi de la livraison d’une
documentation claire et précise.
Organisation et production
Pour un projet d’une telle envergure et comme le Sprint 1: Refonte visuel du site web principal en
veut la méthode agile, il convient de faire un Drupal 7
ensemble de cérémonie permettant de mieux
Sprint 2: Refonte visuel en Drupal 10
appréhender, comprendre et organiser la gestion du
projet au détail près. Sprint 3: Migration de la plateforme vers Drupal 10

Il s’en suivra donc un découpage agile du projet en Sprint 4: Configuration et paramétrage du site web
sprint. sur Drupal 10

Découpage sprint prévisionnel

Sprint 5: Installation et configuration du multisite en
Drupal 10
Sprint 0: Installation et configuration des
Sprint 6: Refonte visuel du Multisite
environnements de travail
Organisation et production
Sprint 7: Migration des contenues des sites vers le multisite

Sprint 8: Refonte visuel de l’intranet sur Drupal 10

Sprint 9: Migration des contenues de l’intranet vers la

plateforme Drupal 10

Sprint 10: Configuration et paramétrage de l’intranet sur

Drupal 10
Conclusion
Le présent document tient lieu de présentation de notre compréhension du besoin et peut
donc servir de support de base pour une compréhension clair de ce projet.

Si le besoin de plus d’information sur une des sections se fait sentir, nous sommes disposés
à répondre à celui-ci avec le plus de détails nécessaire.