Skip to contentKHARITA CHALLENGES LAUNCHđ Kharita Challenges is live â Solve real GIS challenges, build your skills, earn verifiable certifications, and showcase your work.
Explore Kharita Challenges Gestion de projet SIG : méthode, étapes et piÚges | KharitaGuides & tutorielsFrançais··29 min read·By Kharita
Gestion de projet SIG : méthode, étapes et piÚges
Comment réussir un projet SIG : cadrage, données, architecture, qualité, recette, déploiement et maintenance, avec une méthode concrÚte.

âșSommaire40 sections40 sections
Gestion de projet SIG : la méthode complÚte, du besoin à la maintenance
Le jour de la recette, tout semble fonctionner. La carte sâouvre, la recherche
retrouve une adresse et le tableau de bord affiche des indicateurs. Puis arrivent
les questions gĂȘnantes : quelle couche fait foi ? Qui validera la prochaine mise
à jour ? Pourquoi deux équipes utilisent-elles des systÚmes de coordonnées
diffĂ©rents ? Peut-on restaurer la base aprĂšs une erreur ? Lâapplication terrain
fonctionne-t-elle sans réseau ?
Une démonstration réussie ne suffit pas. Un projet SIG est réussi lorsque des
utilisateurs prennent une meilleure décision, avec des données dont la qualité
est comprise, dans un systĂšme que lâorganisation sait exploiter et faire
Ă©voluer. La carte nâest que la partie visible de cette chaĂźne.
Ce guide propose une méthode complÚte pour passer du problÚme métier à un
service gĂ©ospatial durable. Elle sâapplique Ă un inventaire de rĂ©seau, une
application de collecte, un observatoire territorial, une infrastructure de
données spatiales, un traitement de télédétection ou un WebSIG. Elle synthétise
les pratiques de gestion de projet, les normes relatives Ă lâinformation
gĂ©ographique et lâexpĂ©rience des projets numĂ©riques. Ce nâest pas une nouvelle
norme : chaque Ă©quipe doit lâadapter Ă son risque, Ă sa taille et Ă son contexte.
Le cycle de vie relie la valeur mĂ©tier, les donnĂ©es, la livraison et lâexploitation. Gouvernance, qualitĂ© et sĂ©curitĂ© traversent toutes les phases.SchĂ©ma original Kharita, palette officielle, 2026
Le cycle ne sâarrĂȘte pas Ă la mise en ligne. Lâexploitation produit de nouveaux
retours qui peuvent conduire à reprendre le cadrage, les données ou le produit.
Pourquoi un projet SIG nâest pas un simple projet de carte
Dans un projet classique, demander « une nouvelle donnĂ©e » peut sembler ĂȘtre
une petite évolution. Dans un SIG, cette demande peut engager une licence, une
mĂ©thode dâacquisition, une emprise, un systĂšme de rĂ©fĂ©rence, un modĂšle
dâattributs, une transformation, des rĂšgles topologiques, un style, un niveau
dâaccĂšs, un pipeline de mise Ă jour et des coĂ»ts rĂ©currents.
Il faut donc piloter cinq chantiers en parallĂšle.
| Chantier | Question centrale | Preuve attendue |
|---|
| Usage mĂ©tier | Quelle dĂ©cision ou opĂ©ration doit ĂȘtre amĂ©liorĂ©e ? | Cas dâusage priorisĂ© et indicateur de rĂ©sultat |
| Données | Que sait-on, à quelle date, avec quelle qualité et quels droits ? | Inventaire, spécification, métadonnées et rapport qualité |
| Technologie | Comment acquérir, traiter, stocker et diffuser ? | Architecture, pipelines, services et applications |
| Organisation | Qui décide, produit, contrÎle, publie et corrige ? | Gouvernance, responsabilités et procédures |
| Exploitation | Qui maintient le service et finance les mises à jour ? | Runbook, support, sauvegardes et budget récurrent |
Ces chantiers se contraignent mutuellement. Une interface élégante ne rattrape
pas un référentiel sans propriétaire. Une donnée centimétrique ne compense pas
un processus métier contradictoire. Une API rapide ne garantit pas que sa
source sera encore actualisée dans deux ans.
Le PMBOK Guide, 8e édition, publié en
novembre 2025, met lâaccent sur la valeur, lâadaptation au contexte et la
responsabilité. Il organise le management de projet autour de six principes et
sept domaines de performance. Ce cadre général est utile pour le pilotage ; il
ne remplace toutefois ni la spécification des données géographiques, ni leur
contrĂŽle, ni la conception dâun service SIG.
Deux repĂšres du PMBOK Guide â 8e Ă©dition- Principes fondamentaux
- 6
- Domaines de performance
- 7
Project Management Institute, PMBOK Guide â Eighth Edition, novembre 2025
Ces nombres décrivent le référentiel général du PMI. Ils ne constituent ni
treize Ă©tapes Ă exĂ©cuter, ni une mĂ©thode SIG prĂȘte Ă lâemploi.
La mĂ©thode en un coup dâĆil
La méthode proposée ici tient en huit phases. Chacune répond à une question,
produit des livrables et se termine par une décision explicite.
| Phase | Question directrice | Livrables minimaux | Décision de passage |
|---|
| 1. Cadrer | Quel problĂšme mĂ©rite dâĂȘtre rĂ©solu ? | Charte, sponsor, pĂ©rimĂštre, indicateurs | Le projet crĂ©e-t-il une valeur identifiable ? |
| 2. Gouverner | Qui décide et comment travaille-t-on réellement ? | Parties prenantes, RACI, parcours métier | Les responsabilités et arbitrages sont-ils clairs ? |
| 3. Qualifier | Les donnĂ©es conviennent-elles Ă lâusage ? | Inventaire, droits, qualitĂ© initiale, lacunes | Produire, acheter, corriger ou renoncer ? |
| 4. Concevoir | Que doit fournir le produit et comment ? | Exigences, modÚle, architecture, plan qualité | La solution est-elle testable et exploitable ? |
| 5. Prototyper | Les hypothĂšses tiennent-elles sur un cas rĂ©el ? | Pilote vertical, mesures, liste dâĂ©carts | Continuer, corriger ou arrĂȘter ? |
| 6. Livrer | Comment produire sans perdre la maĂźtrise ? | IncrĂ©ments, tests, documentation, dĂ©cisions | LâincrĂ©ment est-il rĂ©ellement terminĂ© ? |
| 7. Recetter | Quelles preuves autorisent lâacceptation ? | RĂ©sultats, anomalies, traçabilitĂ©, procĂšs-verbal | Production, rĂ©serve ou rejet ? |
| 8. Exploiter | Qui maintient la donnĂ©e et le service ? | Runbook, support, mises Ă jour, revue des bĂ©nĂ©fices | Le service peut-il vivre sans lâĂ©quipe projet ? |
Lâordre est logique, pas rigide. Un risque dĂ©couvert pendant le pilote peut
renvoyer vers lâaudit des donnĂ©es. Une contrainte de sĂ©curitĂ© peut modifier
lâarchitecture. Une faible adoption peut conduire Ă reprendre un parcours
métier. Le pilotage sert précisément à rendre ces boucles visibles, décidables
et traçables.
Phase 1 â Cadrer la dĂ©cision avant de choisir lâoutil
« Nous voulons une carte interactive » nâest pas encore un besoin. Câest une
solution supposĂ©e. Le cadrage doit remonter Ă la situation que lâon veut
changer : localiser plus vite un équipement, réduire les doubles saisies,
prioriser une inspection, partager un référentiel commun, détecter une
évolution ou expliquer une décision.
Une bonne formulation contient quatre éléments :
- lâutilisateur ou le service concernĂ© ;
- la dĂ©cision ou lâopĂ©ration Ă amĂ©liorer ;
- lâinformation spatiale nĂ©cessaire au bon moment ;
- un résultat observable avant et aprÚs le projet.
Par exemple, « créer un WebSIG du réseau » reste vague. « Permettre à un agent
dâidentifier lâorgane dâisolement, ses caractĂ©ristiques et son historique
depuis le terrain, afin de rĂ©duire le dĂ©lai de prĂ©paration dâune intervention »
donne déjà des utilisateurs, un workflow, des données et un indicateur.
La charte dâune page
Avant un cahier des charges volumineux, une charte courte force les décisions
essentielles.
| Champ | Contenu attendu |
|---|
| ProblĂšme | Situation actuelle et coĂ»t de lâinaction |
| Résultat visé | Décision ou opération améliorée |
| Utilisateurs | Profils, contexte dâusage et frĂ©quence |
| PérimÚtre | Territoire, métiers, données et fonctions incluses |
| Hors périmÚtre | Ce que le projet ne promet pas |
| Sponsor | Personne capable dâarbitrer ressources et prioritĂ©s |
| Indicateurs | Mesures de résultat, avec valeur initiale si possible |
| HypothÚses critiques | Données, accÚs, disponibilité métier, infrastructure |
| Contraintes | Délai, budget, droit, sécurité, connectivité |
Le bon indicateur mesure un effet, pas seulement une production. « 40 couches
publiĂ©es » compte une sortie. « Le temps mĂ©dian de recherche dâun dossier passe
de 20 Ă 5 minutes » mesure une amĂ©lioration. Les deux peuvent ĂȘtre suivis, mais
ils ne racontent pas la mĂȘme rĂ©ussite.
Le cadrage doit aussi protéger le projet contre le périmÚtre implicite. Une
carte nationale, une application mobile, un géocodage, des tableaux de bord et
une migration historique ne sont pas cinq boutons dâun mĂȘme Ă©cran : ce sont
des produits avec des dépendances et des risques différents.
Phase 2 â Installer la gouvernance et observer le travail rĂ©el
Un SIG croise souvent plusieurs mĂ©tiers. LâĂ©quipe technique maĂźtrise la base,
mais pas nécessairement la rÚgle de gestion. Le service métier connaßt les
exceptions, mais pas toujours les limites des données. Le commanditaire finance,
mais ne peut pas valider chaque attribut. Sans répartition explicite, toutes les
décisions remontent au chef de projet, puis restent en attente.
Une matrice RACI simple distingue quatre rÎles : R réalise, A assume la
responsabilité finale et valide, C est consulté, I est informé. Les noms
de postes importent moins que les questions concrĂštes :
- qui accepte la dĂ©finition dâun objet et ses attributs ;
- qui autorise une publication ;
- qui traite les anomalies ;
- qui arbitre un changement de périmÚtre ;
- qui assume la donnée aprÚs la fin du projet.
Une activité devrait conserver une autorité clairement identifiable. Deux
services « A » sur la mĂȘme rĂšgle mĂ©tier produisent souvent un conflit ; aucun
service « A » produit un vide.
Aller voir le travail au lieu de dessiner le workflow en salle
Les ateliers sont nécessaires, mais ils décrivent volontiers le processus
thĂ©orique. Lâobservation rĂ©vĂšle le vrai systĂšme : tableaux personnels, photos
envoyées par messagerie, codes mémorisés, corrections sur papier, absence de
réseau, doublons tolérés et exceptions jamais documentées.
Pour chaque parcours prioritaire, documentez :
- le déclencheur ;
- les personnes et systÚmes impliqués ;
- les données lues ou modifiées ;
- les décisions et validations ;
- les exceptions ;
- le résultat et la preuve de fin.
Cette enquĂȘte Ă©vite un piĂšge courant : numĂ©riser un mauvais processus. Ajouter
une carte Ă trois validations redondantes ne rend pas lâorganisation plus
rapide ; cela déplace seulement la lenteur dans un nouvel écran.
Le cadrage rĂ©unit le mĂ©tier, la donnĂ©e et la technique autour des mĂȘmes dĂ©cisions. Les cartes et les Ă©crans servent la discussion ; ils ne remplacent ni le sponsor, ni les responsabilitĂ©s, ni les arbitrages.Illustration originale Kharita â Imagen, 2026Phase 3 â Qualifier les donnĂ©es avant de promettre le produit
Lâinventaire ne doit pas ĂȘtre une liste de fichiers. Câest un diagnostic
dâaptitude Ă lâusage. Deux couches portant le mĂȘme nom peuvent diffĂ©rer par
lâannĂ©e, lâemprise, la prĂ©cision, la dĂ©finition des objets ou le droit de
réutilisation.
Pour chaque source, relevez au minimum :
| Dimension | Questions Ă poser |
|---|
| Identité | Producteur, titre, version, responsable et identifiant stable |
| Espace | Emprise, résolution ou échelle, SCR, datum et transformation |
| Temps | Date dâobservation, date de publication, frĂ©quence et retard de mise Ă jour |
| Sémantique | Définition des objets, champs, unités, nomenclatures et valeurs nulles |
| Qualité | Complétude, cohérence, position, classification, contrÎles déjà réalisés |
| Droit | Licence, contrat, attribution, restrictions, données personnelles ou sensibles |
| Technique | Format, volume, encodage, index, dĂ©pendances et mĂ©thode dâaccĂšs |
| Cycle de vie | Source de mise Ă jour, responsable, archivage et date de retrait |
La qualitĂ© gĂ©ographique se construit dĂšs le terrain : protocole de collecte, positionnement, attributs obligatoires, contrĂŽle de cohĂ©rence et traçabilitĂ© de la synchronisation.Illustration originale Kharita â Imagen, 2026La question dĂ©cisive nâest pas « la donnĂ©e est-elle bonne ? », mais est-elle
assez bonne pour cet usage ? Une grille Ă 100 mĂštres peut convenir Ă une
analyse rĂ©gionale et ĂȘtre dangereuse pour positionner un Ă©quipement. Une
adresse approximative peut suffire Ă produire une statistique agrĂ©gĂ©e et ĂȘtre
insuffisante pour envoyer une Ă©quipe dâintervention.
Lorsque la source nâest pas encore disponible, le planning doit montrer la
dĂ©pendance rĂ©elle : nĂ©gociation dâaccĂšs, achat, levĂ©, numĂ©risation, nettoyage ou
production par télédétection. Présenter cette donnée comme « fournie au
démarrage » ne réduit pas le risque ; cela le cache.
Une donnĂ©e trouvĂ©e en ligne nâest pas automatiquement libre de droits. Le
registre des sources doit conserver la licence ou le contrat, lâURL, la date de
téléchargement, la version, les transformations effectuées et la personne ayant
validĂ© lâusage. Les principes FAIR
â trouvable, accessible, interopĂ©rable et rĂ©utilisable â constituent une bonne
grille de lecture, mais FAIR ne signifie ni « ouvert », ni « exact », ni
« libre de toute restriction ».
Cette phase est aussi celle oĂč un catalogue de donnĂ©es devient utile. Sur
Kharita, par exemple, la prévisualisation, la description des
variables, la pĂ©riode et la source permettent dâĂ©valuer un jeu de donnĂ©es avant
de lâintĂ©grer. Le catalogue ne dispense jamais de vĂ©rifier sa licence, sa
résolution et son adéquation au projet.
Phase 4 â SpĂ©cifier la donnĂ©e, le service et lâarchitecture
Le cahier des charges doit transformer le besoin en engagements testables.
« Carte moderne », « données précises » et « application rapide » ne sont pas
des exigences : personne ne peut les mesurer de maniÚre non ambiguë.
Une exigence utile prĂ©cise le contexte, lâaction, le rĂ©sultat et, lorsque cela
compte, un seuil. Par exemple :
Depuis une tablette hors connexion, un agent autorisé peut créer un équipement,
renseigner les champs obligatoires, joindre deux photos, puis synchroniser la
saisie sans doublon aprÚs le retour du réseau.
Traiter la donnée comme un produit
La norme ISO 19131:2022 fournit un
cadre pour spécifier un produit de données géographiques. Dans la pratique, une
spécification doit décrire :
- le pĂ©rimĂštre et lâusage prĂ©vu ;
- le catalogue des objets, attributs et relations ;
- le systÚme de référence et les transformations ;
- les exigences de qualitĂ© et leur mĂ©thode dâĂ©valuation ;
- les métadonnées, formats et modes de livraison ;
- la fréquence de mise à jour et la gestion des versions.
ISO 19157-1:2023 structure la
description et lâĂ©valuation de la qualitĂ© gĂ©ographique. Elle ne fixe pas une
précision minimale universelle : les seuils appartiennent au projet et doivent
dĂ©couler de lâusage. Dire « conforme ISO 19157 » sans mesure, sans pĂ©rimĂštre et
sans seuil nâest donc pas une recette.
Séparer fonctions et qualités de service
Les exigences fonctionnelles décrivent ce que le systÚme permet de faire :
rechercher, éditer, calculer, exporter, alerter. Les exigences non fonctionnelles
décrivent la maniÚre dont il doit le faire : performance, sécurité,
disponibilité, accessibilité, compatibilité, auditabilité et maintenabilité.
Le modĂšle ISO/IEC 25010:2023 offre un
vocabulaire Ă neuf caractĂ©ristiques pour examiner la qualitĂ© dâun produit
logiciel ou numérique ; les objectifs chiffrés restent à définir selon le
service.
Concevoir par responsabilités, pas par marques
Une architecture saine part des fonctions Ă assurer : sources, ingestion,
contrÎle, référentiel spatial, services, applications, supervision et
sauvegarde. Les produits sont choisis ensuite selon les compétences, le budget,
les contraintes dâhĂ©bergement, le besoin dâinteropĂ©rabilitĂ© et le coĂ»t de sortie.
Lâarchitecture est organisĂ©e par responsabilitĂ©s : collecter, contrĂŽler, stocker, servir et utiliser. Les technologies sont choisies ensuite.SchĂ©ma original Kharita, palette officielle, 2026Cette lecture par responsabilitĂ©s facilite les choix techniques : les logiciels
peuvent évoluer sans redessiner le besoin ni perdre la fonction assurée par
chaque bloc.
LâinteropĂ©rabilitĂ© doit Ă©galement ĂȘtre reliĂ©e Ă un usage. Les standards de
lâOpen Geospatial Consortium couvrent notamment
les entités, les cartes, les tuiles, les catalogues et les traitements. Un WMS
reste pertinent pour une carte rendue cĂŽtĂ© serveur ; une API dâentitĂ©s convient
mieux Ă une consultation objet par objet ; des tuiles rĂ©pondent Ă dâautres
contraintes de diffusion. Ăcrire seulement « API REST » ne prouve aucune
interopérabilité.
Enfin, documentez les dĂ©cisions dâarchitecture : option retenue, alternatives,
raison, conséquences et date de réexamen. Cette courte mémoire évite de rouvrir
la mĂȘme discussion tous les trois mois.
Phase 5 â Prototyper pour rĂ©duire lâincertitude
Une maquette valide une apparence. Un pilote valide un systĂšme sur une tranche
de bout en bout : une source réelle, un traitement, un référentiel, un service,
un utilisateur et une dĂ©cision. Câest la diffĂ©rence entre montrer un Ă©cran et
tester une hypothĂšse.
Un pilote utile réunit :
- une géographie et un volume représentatifs ;
- des cas simples et des exceptions difficiles ;
- les appareils, rĂ©seaux et profils dâaccĂšs prĂ©vus ;
- de vrais utilisateurs ;
- des critĂšres de poursuite, de correction et dâarrĂȘt.
Tester 300 objets propres sur un ordinateur puissant ne prouve pas quâune base
de 20 millions dâentitĂ©s supportera les mises Ă jour concurrentes. Tester une
application terrain dans un bureau connecté ne prouve pas sa synchronisation
hors ligne. Le pilote doit attaquer les hypothÚses les plus risquées, pas celles
qui donnent la meilleure démonstration.
Prédictif, agile ou hybride ?
Le choix dĂ©pend surtout de lâincertitude. ISO 21502:2020
sâapplique Ă des approches prĂ©dictives, itĂ©ratives, adaptatives ou hybrides. Le
PMI Agile Practice Guide, 2e édition,
publié en juillet 2026, traite lui aussi le choix comme un continuum adapté au
contexte.
| Situation | Approche souvent adaptée | Vigilance |
|---|
| Produit de donnĂ©es et seuils stables | PrĂ©dictive | Ne pas dĂ©couvrir trop tard que le produit ne rĂ©pond pas Ă lâusage |
| Interface et parcours encore incertains | Adaptative | Ne pas laisser le modÚle de données dériver à chaque sprint |
| Socle critique stable, usages à affiner | Hybride | Dire clairement ce qui est fixe et ce qui peut évoluer |
| Recherche, GeoAI ou extraction incertaine | Expérimentale avec jalons stop/go | Ne pas promettre une précision avant validation indépendante |
| Livrables contractuels et expérience utilisateur complexe | Hybride avec réceptions formelles | Ne pas confondre revue de sprint et acceptation contractuelle |
Pour beaucoup de projets SIG, lâhybride est pragmatique : droits, rĂ©fĂ©rentiel,
sécurité, architecture structurante et critÚres de recette sont cadrés ; les
parcours utilisateur et certaines analyses Ă©voluent par itĂ©rations. Ce nâest
pas une rĂšgle universelle, mais une façon de placer la flexibilitĂ© lĂ oĂč elle
produit de lâapprentissage sans fragiliser le socle.
La mĂ©thode hybride stabilise les invariants critiques, construit les usages par incrĂ©ments puis impose des dĂ©cisions formelles avant le pilote, la production et le transfert.SchĂ©ma original Kharita, palette officielle, 2026LâagilitĂ© ne dispense ni de projection correcte, ni de droits dâusage, ni de
seuils de qualitĂ©. Elle organise lâapprentissage autour dâincrĂ©ments
utilisables, tandis que les décisions critiques restent contrÎlées.
Phase 6 â Livrer par incrĂ©ments sans perdre la traçabilitĂ©
Un incrĂ©ment SIG ne devrait pas ĂȘtre une couche de technologie isolĂ©e. « Faire
la base », puis « faire lâAPI », puis « faire lâinterface » retarde le premier
retour métier. Préférez des tranches verticales : un workflow prioritaire, avec
ses données, sa rÚgle, son traitement, son écran et ses tests.
Une définition de « terminé » peut exiger :
- données ou migration versionnées ;
- contrÎles automatiques exécutés ;
- code relu et tests passés ;
- exigence reliée à une preuve ;
- documentation et métadonnées mises à jour ;
- démonstration au référent métier ;
- anomalies critiques résolues ;
- impacts dâexploitation examinĂ©s.
La matrice de traçabilité
La traçabilité relie chaque besoin important à sa conception, son test et sa
décision. Elle peut rester simple.
| ID | Exigence | Source | Priorité | Méthode de test | Preuve | Statut |
|---|
| DAT-07 | Identifiant unique obligatoire | Responsable donnĂ©es | Critique | RequĂȘte dâunicitĂ© et de nullitĂ© | Rapport SQL horodatĂ© | Ă tester |
| MOB-03 | Saisie et synchronisation hors ligne | Ăquipe terrain | Critique | ScĂ©nario sans rĂ©seau puis reconnexion | Journal de test | Ă tester |
| API-04 | Consultation par emprise | DĂ©veloppeurs clients | Haute | RequĂȘtes sur jeux de charge | Rapport API | Ă tester |
La matrice protÚge contre deux dérives : une fonctionnalité construite sans
besoin et une exigence annoncée sans test.
Piloter les décisions, changements et risques
Un compte rendu de réunion raconte les échanges. Un journal de décisions
conserve ce qui a été tranché, par qui, sur quelles hypothÚses et avec quelles
consĂ©quences. Un registre de changements ajoute lâimpact sur le pĂ©rimĂštre, le
dĂ©lai, le coĂ»t, la qualitĂ© et lâexploitation avant lâapprobation.
Le registre de risques doit décrire un événement, sa cause et sa conséquence.
« DonnĂ©es » nâest pas un risque. « Le fournisseur peut livrer la nouvelle
orthophoto aprĂšs la migration, ce qui imposerait de reprendre le contrĂŽle
géométrique et décalerait la recette » en est un. Ajoutez un propriétaire, une
prévention, un déclencheur et un plan de réponse.
ISO 31000:2018 fournit des principes
et un processus de management du risque. Elle nâimpose pas une matrice 5 Ă 5 ni
une formule unique. Si lâĂ©quipe utilise un score, elle doit dĂ©finir clairement
les échelles et ne pas laisser un total masquer un risque rare mais
inacceptable.
Phase 7 â Recetter trois produits, pas un seul
Une recette sérieuse examine séparément la donnée, le service logiciel
et la capacitĂ© dâexploitation. Ouvrir trois couches dans un navigateur ne
valide aucun de ces produits Ă lui seul.
Une recette complĂšte accepte sĂ©parĂ©ment les donnĂ©es, le service et la capacitĂ© dâexploitation, avec une exigence, un test, un seuil, une preuve et un responsable.SchĂ©ma original Kharita, palette officielle, 2026La preuve de recette doit ĂȘtre reproductible : rapport, jeu de test, journal,
version et responsable de la dĂ©cision. La rĂ©ussite dâun volet ne compense pas
une défaillance critique dans un autre.
Assurance qualité et contrÎle qualité
Lâassurance qualitĂ©, ou QA, agit avant et pendant la production : dictionnaire
de données, rÚgles de saisie, contraintes en base, revue de code, procédures de
transformation, formation et automatisation. Le contrÎle qualité, ou QC,
inspecte les résultats : doublons, géométries invalides, erreurs topologiques,
écarts positionnels, valeurs interdites, trous de couverture et sorties
incorrectes.
Prévenir et détecter sont complémentaires. Une équipe qui ne fait que du QC
découvre tard des milliers de défauts semblables. Une équipe qui ne fait que de
la QA suppose que sa procédure fonctionne sans jamais le vérifier.
Ăcrire des critĂšres mesurables
Chaque critĂšre dâacceptation devrait comporter cinq Ă©lĂ©ments : exigence,
méthode de test, jeu ou périmÚtre testé, seuil et preuve.
| Objet | Exigence testable | Preuve possible |
|---|
| Identifiants | Aucun identifiant nul ou dupliquĂ© dans le lot acceptĂ© | RequĂȘte et rapport signĂ©s |
| GĂ©omĂ©trie | Les gĂ©omĂ©tries respectent les rĂšgles convenues, exceptions documentĂ©es | Rapport QA et couche dâanomalies |
| RĂ©seau | Chaque extrĂ©mitĂ© est raccordĂ©e Ă un nĆud ou Ă une exception autorisĂ©e | Test topologique reproductible |
| Performance | Le p95 reste sous le seuil convenu pour une charge donnée | Script et rapport de charge |
| AccÚs | Chaque rÎle ne voit et ne modifie que les objets autorisés | Matrice et journal de tests |
| Sauvegarde | Une restauration complĂšte rĂ©ussit dans lâenvironnement de test | ProcĂšs-verbal de restauration |
| Usage | Les scénarios critiques sont exécutés par les utilisateurs désignés | PV de recette utilisateur |
Les seuils ci-dessus doivent ĂȘtre fixĂ©s par le projet. Une norme ne dĂ©crĂšte pas
quâune prĂ©cision de 1 mĂštre est bonne, ni quâun temps de 2 secondes convient Ă
tous les services.
Une grille pondĂ©rĂ©e peut aider Ă organiser la dĂ©cision de recette. Lâexemple
suivant est illustratif, pas un barĂšme universel.
Exemple de pondĂ©ration dâune recette SIGEn % de la note de recette
Exemple Ă©ditorial Kharita Ă adapter au risque et aux prioritĂ©s du projet ; ces pondĂ©rations ne proviennent dâaucune norme.
➠Voir les données
| Données et qualité géographique | 40 |
|---|
| Fonctions et parcours métier | 25 |
|---|
| Performance et sécurité | 20 |
|---|
| Exploitation et transfert | 15 |
|---|
Une pondération ne doit jamais permettre de compenser une exigence critique.
Un excellent score dâergonomie ne rachĂšte pas une fuite de donnĂ©es, une
transformation de coordonnĂ©es erronĂ©e ou lâimpossibilitĂ© de restaurer le
systĂšme. Les critĂšres Ă©liminatoires doivent ĂȘtre identifiĂ©s sĂ©parĂ©ment.
Phase 8 â DĂ©ployer, transfĂ©rer et exploiter
La mise en production est un changement dâorganisation, pas seulement un
changement de serveur. Il faut préparer la migration, les rÎles, la formation,
le support de démarrage, la communication, la reprise des données et le retour
arriĂšre.
Une formation utile suit les scénarios de travail : créer une inspection,
valider une anomalie, corriger un objet, publier une version, diagnostiquer un
Ă©chec dâimport. Une visite guidĂ©e de lâinterface transmet des boutons ; elle ne
crĂ©e pas lâautonomie.
La mise en production engage plusieurs responsabilitĂ©s : le mĂ©tier accepte les usages, lâĂ©quipe donnĂ©es vĂ©rifie les rĂ©fĂ©rentiels et lâexploitation prouve quâelle sait surveiller, sauvegarder et restaurer le service.Illustration originale Kharita â Imagen, 2026Le dossier dâexploitation minimal
Avant la clĂŽture du projet, lâĂ©quipe qui reprend le service doit disposer de :
- responsables nommĂ©s pour lâapplication et chaque donnĂ©e critique ;
- procédure de déploiement et de retour arriÚre ;
- supervision, alertes et journaux exploitables ;
- sauvegarde et restauration réellement testées ;
- calendrier de mise Ă jour et traitement des rejets ;
- gestion des comptes, rĂŽles, certificats et secrets ;
- support, niveaux de service et procĂ©dure dâincident ;
- code, configuration, dépendances, licences et versions ;
- documentation des données, API et transformations ;
- plan de réversibilité et formats de restitution.
Le coĂ»t doit ĂȘtre examinĂ© sur le cycle de vie :
TCO = acquisition + intégration + infrastructure + licences + sécurité + support + mises à jour + formation + réversibilité
Ce nâest pas une formule comptable universelle. Câest un rappel : le
dĂ©veloppement initial nâest quâune partie du coĂ»t. Une solution peu chĂšre Ă
lâachat devient coĂ»teuse si personne ne sait actualiser les donnĂ©es, si chaque
import demande une intervention manuelle ou si la sortie du fournisseur est
impossible.
Enfin, mesurez les bĂ©nĂ©fices aprĂšs la mise en service. Taux dâutilisation,
délai de traitement, erreurs évitées, couverture des données, fréquence de mise
à jour et satisfaction des utilisateurs peuvent montrer si le produit résout
rĂ©ellement le problĂšme initial. Sans cette revue, le projet sait quâil a livrĂ© ;
il ne sait pas sâil a rĂ©ussi.
Huit piÚges qui font échouer les projets SIG
| PiĂšge | SymptĂŽme visible | Correction utile |
|---|
| Commencer par le logiciel | Débat de licences avant le besoin | Décrire la décision, les workflows et les contraintes |
| Confondre source et donnĂ©e prĂȘte | Les fichiers arrivent tard et ne sâassemblent pas | Auditer tĂŽt, chiffrer le nettoyage et traiter les lacunes |
| Ignorer la dimension temporelle | Personne ne sait quel millésime comparer | Définir observation, publication, validité et mise à jour |
| Tester sur une démo propre | Le pilote évite volumes et exceptions | Choisir un cas représentatif et difficile |
| Ăcrire des exigences vagues | La recette devient une nĂ©gociation | Relier chaque exigence Ă un seuil et une preuve |
| Faire de lâagile sans socle | SchĂ©ma et rĂšgles changent Ă chaque sprint | Stabiliser les invariants et versionner les dĂ©cisions |
| Former Ă la fin | Les utilisateurs dĂ©couvrent trop tard les erreurs de workflow | Les impliquer au pilote et aux revues dâincrĂ©ment |
| ClĂŽturer Ă la mise en ligne | Plus personne nâactualise les couches | Financer et attribuer lâexploitation avant le go-live |
Un neuviĂšme piĂšge traverse les huit autres : lâoptimisme silencieux. Lorsquâune
dĂ©pendance critique est « probablement disponible », quâun contrĂŽle sera « fait
plus tard » ou quâun service « devrait reprendre la donnĂ©e », transformez cette
phrase en hypothĂšse avec un responsable et une date de validation.
Adapter la méthode au contexte marocain
La mĂ©thode reste la mĂȘme, mais quelques vĂ©rifications prennent une importance
particuliÚre dans un projet réalisé au Maroc.
Un traitement permettant dâidentifier directement ou indirectement une
personne doit ĂȘtre examinĂ© au regard de la loi 09-08 et des procĂ©dures de la
CNDP.
Toutes les coordonnées ne sont pas personnelles : le risque dépend de la
granularité, de la finalité et de la possibilité de relier une position à un
employé, un véhicule, une adresse ou une trace individuelle.
Pour les organismes et systÚmes concernés, les référentiels de la
DGSSI
peuvent ajouter des exigences de gouvernance, dâaccĂšs, de dĂ©veloppement, de
fournisseurs, dâincidents et de continuitĂ©. Leur applicabilitĂ© se vĂ©rifie au cas
par cas ; elle ne doit pas ĂȘtre attribuĂ©e automatiquement Ă tout petit projet.
Un marché public doit aligner livrables, droits, réceptions et réversibilité sur
le cadre marocain applicable.
Le contrat ne doit pas se contenter de nommer une « base SIG » : il doit définir
les données, la qualité, les formats de restitution, le code, la documentation,
les environnements et les preuves dâacceptation.
Pour un pĂ©rimĂštre national, lâemprise validĂ©e par le maĂźtre dâouvrage doit ĂȘtre
testĂ©e dans son intĂ©gralitĂ©, provinces du Sud incluses. Le fond de carte dâun
tiers ne doit pas décider silencieusement de la couverture du produit. Les
trous de raster au littoral, les découpes involontaires et les écarts de
rĂ©solution demandent des contrĂŽles mesurĂ©s, pas une simple capture dâĂ©cran.
Enfin, anticipez les référentiels de coordonnées utilisés, les transformations,
les libellĂ©s français et arabes, les variantes toponymiques, lâaffichage de
droite Ă gauche lorsquâil est requis et la connectivitĂ© intermittente des
équipes de terrain. Ce sont des exigences de départ, pas des corrections
dâinterface Ă ajouter la veille de la recette.
Checklist avant de lancer un projet SIG
Le besoin
Les données
La solution
Lâacceptation et la suite
Conclusion
GĂ©rer un projet SIG, ce nâest pas tenir un planning autour dâune carte. Câest
organiser une chaßne de confiance entre un besoin, des données, une décision et
une exploitation durable.
La méthode peut se résumer ainsi : cadrer la valeur, nommer les
responsabilités, qualifier la donnée, tester tÎt les hypothÚses risquées,
livrer par preuves et prĂ©parer lâexploitation avant la mise en ligne. Le bon
chef de projet ne promet pas que tout est certain. Il rend les incertitudes
visibles assez tĂŽt pour que lâorganisation puisse dĂ©cider.
Questions fréquentes
Quelles sont les principales Ă©tapes dâun projet SIG ?
Un projet SIG passe généralement par le cadrage du besoin, la gouvernance,
lâaudit des donnĂ©es, la spĂ©cification, lâarchitecture, le pilote, la rĂ©alisation,
la recette, le dĂ©ploiement et lâexploitation. Ces Ă©tapes peuvent se chevaucher,
mais chacune doit produire des preuves et une décision de passage.
Le SIG ajoute des contraintes spatiales et temporelles : emprise, systĂšme de
référence, précision, topologie, résolution, millésime, provenance et qualité
géographique. Il doit aussi maintenir une chaßne entre acquisition, traitement,
publication et mise Ă jour.
Partez des décisions et scénarios métier. Décrivez ensuite les données, les
fonctions, les qualités de service, les rÎles, les contraintes, les livrables et
les critĂšres de recette. Chaque exigence critique doit ĂȘtre testable et reliĂ©e Ă
une preuve.
Faut-il choisir le cycle en V ou une méthode agile ?
Il nâexiste pas de rĂ©ponse unique. Le prĂ©dictif convient mieux aux livrables et
seuils stables ; lâadaptatif aide lorsque lâusage reste incertain. Une approche
hybride stabilise souvent le socle des données, de la sécurité et de la recette,
tout en itérant sur les parcours et fonctions.
Quelle est la différence entre une maquette et un pilote SIG ?
La maquette valide surtout une représentation ou une ergonomie. Le pilote teste
une tranche de bout en bout avec données, volume, traitement, accÚs,
utilisateur et conditions réels. Il doit pouvoir invalider une hypothÚse.
DĂ©finissez Ă lâavance les contrĂŽles de schĂ©ma, domaines, identifiants,
géométries, topologie, position, couverture, temporalité et métadonnées. Pour
chaque contrÎle, précisez le périmÚtre, la méthode, le seuil, la preuve et la
dĂ©cision en cas dâĂ©cart.
Quand un projet SIG est-il terminé ?
Le dĂ©veloppement peut ĂȘtre terminĂ© lorsque les livrables sont acceptĂ©s. Le
service, lui, entre alors en exploitation. Il faut que les responsables,
procédures, budgets, sauvegardes, mises à jour et compétences soient déjà en
place. Sans cela, le projet est livrĂ© mais le SIG nâest pas durable.
Quels livrables demander Ă un prestataire SIG ?
Au-delĂ de lâapplication : inventaire et spĂ©cification des donnĂ©es, modĂšle,
métadonnées, scripts et journaux de transformation, code et configuration,
tests, rapports QA, documentation des API, procédure de déploiement, sauvegarde,
restauration, runbook, formation et plan de réversibilité.
Sources et références