Certains projets vous poussent dans vos derniers retranchements. Le Répertoire National de la Brigade Chrétienne et Lumière d'Haïti (BCLH) est l'un d'eux. Une plateforme nationale, couvrant les 10 départements du pays et la diaspora, avec des milliers d'entrées, une cartographie interactive et zéro budget publicitaire. Voici le récit complet de comment nous l'avons construit — les choix techniques, les erreurs, les solutions et les résultats.

1
Le contexte et le défi initial

La Brigade Chrétienne et Lumière d'Haïti est une organisation chrétienne présente dans tout le pays et dans la diaspora. Elle avait un problème concret : ses membres, ses brigades locales et ses responsables étaient éparpillés sans aucun registre centralisé accessible. Retrouver une brigade dans un département spécifique relevait du bouche-à-oreille.

La demande initiale était claire — construire un répertoire national consultable, structuré par département, accessible depuis n'importe quel appareil, et qui puisse grandir avec l'organisation. Ce qui semblait être un projet de quelques semaines s'est révélé bien plus complexe dès les premières semaines de travail.

Le défi central

Concevoir une plateforme capable d'organiser des milliers d'entrées géographiques sur un pays entier, consultable sur mobile avec des connexions instables, sans infrastructure serveur coûteuse, et maintenue par une équipe non technique côté client.


2
L'architecture technique choisie

Avant d'écrire une seule ligne de code, nous avons passé du temps à choisir la bonne architecture. La contrainte principale : un hébergement stable et abordable, une base de données qui supporte des milliers d'entrées avec des requêtes géographiques, et un front-end rapide même sur connexion 3G.

Voici les choix que nous avons faits et pourquoi :

Front-end
HTML / CSS / JS vanilla
Léger, rapide, compatible avec tous les navigateurs haïtiens
Back-end
Firebase Firestore
Base de données NoSQL en temps réel, sans serveur à gérer
Cartographie
Leaflet.js + OpenStreetMap
Carte interactive gratuite, plus légère que Google Maps
Hébergement
e-monsite
Plateforme maîtrisée, gestion simplifiée pour le client
Recherche
Filtres dynamiques JS
Filtrage côté client par département, commune et statut
SEO
Pages statiques par département
Une URL par département pour maximiser le référencement
Pourquoi Firebase et pas une base SQL classique

Firebase Firestore nous permettait d'éviter toute gestion de serveur, de bénéficier d'un plan gratuit généreux, et surtout de faire des requêtes filtrées par champ géographique sans configuration complexe. Pour une organisation sans équipe technique interne, c'était le bon choix.


3
Les phases du projet

Le projet s'est déroulé en cinq phases distinctes, chacune avec ses propres livrables et ses propres surprises.

1
 
Phase 1 — Semaines 1–2
Collecte et structuration des données
Réception des listes de brigades par département, nettoyage des données, standardisation des formats d'adresses et de coordonnées GPS. La qualité des données reçues était très variable — certaines entrées n'avaient pas de coordonnées, d'autres avaient des noms de communes orthographiés différemment selon les sources.
2
 
Phase 2 — Semaines 3–4
Architecture Firebase et modèle de données
Conception du schéma de données Firestore, création des collections par département, import des premières données et tests de performance avec des requêtes filtrées. Mise en place des règles de sécurité Firebase pour protéger les données en lecture/écriture.
3
 
Phase 3 — Semaines 5–7
Développement de l'interface et de la carte
Construction du répertoire consultable avec filtres dynamiques, intégration de Leaflet.js pour la cartographie interactive, développement du système de recherche par département, commune et nom. Optimisation mobile intensive pour les connexions lentes.
4
 
Phase 4 — Semaine 8
SEO et structure des URLs
Création d'une page dédiée par département avec URL propre, rédaction des balises meta, optimisation des titres et descriptions. Configuration de Google Search Console pour le suivi du référencement dès le lancement.
5
 
Phase 5 — Semaine 9
Tests, lancement et formation
Tests croisés sur Android, iOS et desktop, vérification de toutes les entrées de la carte, lancement progressif avec partage dans les réseaux de la BCLH. Formation de l'équipe cliente pour les mises à jour de données futures.

4
Les défis rencontrés et comment on les a résolus

Ce projet nous a confrontés à des problèmes techniques que nous n'avions pas anticipés. En voici les principaux et les solutions que nous avons trouvées.

Défi 1 — Données géographiques incomplètes

Plusieurs centaines d'entrées n'avaient pas de coordonnées GPS. Les localités haïtiennes sont souvent absentes des bases de données standards comme Google Maps ou OpenStreetMap.

Solution

Géocodage manuel pour les localités critiques, et création d'un système de fallback qui affiche l'entrée dans le répertoire texte même sans coordonnées GPS, sans casser la carte. Les points manquants sont signalés visuellement pour une mise à jour future.

Défi 2 — Initialisation Firebase en double

Lors des tests, Firebase était initialisé plusieurs fois selon le parcours de navigation sur e-monsite, générant des erreurs silencieuses qui empêchaient certains chargements de données.

Solution

Implémentation d'un guard avec getApps() pour vérifier si Firebase est déjà initialisé avant chaque appel. Ce correctif est maintenant appliqué systématiquement sur tous nos projets Firebase.

Défi 3 — Performance sur mobile avec 1000+ marqueurs sur la carte

Afficher tous les marqueurs en même temps sur Leaflet.js rendait la carte inutilisable sur les téléphones d'entrée de gamme courants en Haïti — lag important, zooms saccadés, crashes.

Solution

Implémentation du clustering de marqueurs avec Leaflet.markercluster — les points proches sont regroupés automatiquement selon le niveau de zoom. Réduction de 90% du nombre d'éléments rendus simultanément, navigation fluide même sur 3G.

Défi 4 — Animations CSS bloquant l'affichage sur e-monsite

Les animations d'entrée utilisant IntersectionObserver et opacity: 0 causaient l'invisibilité permanente de certains blocs sur e-monsite, dont le moteur CSS interférait avec les états initiaux.

Solution

Suppression de l'opacity: 0 initial et remplacement de l'IntersectionObserver par des animations CSS pures déclenchées au chargement. Contenu toujours visible, animation conservée.


5
Les résultats obtenus

Six mois après le lancement, les chiffres parlent d'eux-mêmes. Le répertoire est devenu la référence officielle de l'organisation pour retrouver une brigade locale, planifier des visites de terrain et communiquer avec la diaspora.

14 000+
visiteurs uniques sans aucune publicité payante
10/10
départements haïtiens représentés
Diaspora
Canada, USA, France intégrés dans le répertoire
Top 3
Google sur les requêtes "BCLH Haïti" et variantes
Mobile
72% du trafic vient de téléphones
0 crash
depuis le lancement — plateforme stable

Ce répertoire a changé la façon dont nous communiquons en interne. Pour la première fois, n'importe quel responsable peut trouver une brigade dans n'importe quel département en quelques secondes, depuis son téléphone.

— Direction nationale, Brigade Chrétienne et Lumière d'Haïti

Impact SEO

La structure en pages par département a permis au répertoire d'être indexé par Google sur des dizaines de requêtes locales. Le trafic organique représente 94% des visites — aucune dépense publicitaire n'a été nécessaire pour atteindre les 14 000 visiteurs.


6
Ce que ce projet nous a appris

Le Répertoire BCLH a été notre école la plus exigeante. Chaque défi résolu a enrichi notre façon de concevoir les projets suivants. Voici les leçons que nous avons retenues et qui guident aujourd'hui notre approche chez Groupe 3D Consulting.

  • 1 La qualité des données prime sur tout. Un beau front-end ne sauve pas des données mal structurées. Avant de coder, il faut nettoyer, standardiser et valider toutes les données sources. Nous intégrons désormais systématiquement une phase de "data audit" dans chaque projet avec base de données.
  • 2 Concevoir pour la connexion lente, pas pour la fibre. En Haïti, la majorité des utilisateurs naviguent sur 3G ou moins. Chaque kilooctet compte. Ce projet nous a appris à tester sur des connexions throttlées et à optimiser agressivement les assets avant tout lancement.
  • 3 Le SEO se construit dès l'architecture, pas après le lancement. La décision de créer une URL par département — prise dès la phase 1 — est la principale raison du succès organique du répertoire. Ajouter le SEO après coup aurait été beaucoup plus coûteux.
  • 4 Documenter les solutions techniques pour les réutiliser. Le guard Firebase avec getApps(), le clustering Leaflet, la gestion des animations sur e-monsite — ces solutions sont maintenant notre référence pour tous les projets suivants. Chaque bug résolu devient un atout.
  • 5 Former le client est aussi important que livrer le produit. Une plateforme qui ne peut être mise à jour que par ses créateurs est fragile. Nous avons investi du temps dans la formation de l'équipe BCLH pour qu'elle puisse ajouter et modifier des entrées de façon autonome.

Le Répertoire National BCLH reste à ce jour notre projet phare — celui que nous montrons en premier à nos prospects, celui qui illustre le mieux ce que Groupe 3D Consulting sait faire quand un client nous fait confiance sur un projet ambitieux.

Si vous avez un projet similaire — répertoire, plateforme, annuaire, cartographie — nous avons maintenant l'expérience et les outils pour le réaliser efficacement. Parlons-en.

Un projet de plateforme ou répertoire en tête ?

Nous avons l'architecture, l'expérience terrain et la connaissance du contexte haïtien pour le réaliser. Contactez-nous pour en discuter.

DD
David Dérosier
Directeur Technique – Groupe 3D Consulting