Gestion de projet SIG : méthode, étapes et pièges | Kharita
Guides & tutorielsFrançais··29 min de lecture·Par 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.
Discussion
Commentaires
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
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, 2026
Phase 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, 2026
La 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.
Provenance, licence et métadonnées
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, 2026
Cette 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, 2026
L’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, 2026
La 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 SIG
En % 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, 2026
Le 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
La décision ou l’opération à améliorer est formulée sans nom de logiciel.
Les utilisateurs, le sponsor, le périmètre et le hors-périmètre sont connus.
Au moins un indicateur de résultat possède une méthode de mesure.
Les données
Les sources, versions, dates, droits et responsables sont inventoriés.
Le SCR, les transformations, la précision et l’emprise sont explicites.
Les lacunes et le coût de préparation ne sont pas cachés dans « données fournies ».
Une spécification de produit et un plan QA/QC existent.
La solution
Les exigences fonctionnelles et non fonctionnelles sont séparées.
L’architecture couvre sécurité, sauvegarde, supervision et réversibilité.
Le pilote teste un volume, un territoire, des utilisateurs et des exceptions réalistes.
Chaque incrément relie données, traitement, interface, test et documentation.
L’acceptation et la suite
Les critères de recette possèdent méthode, seuil, preuve et responsable.
Les critères éliminatoires sont distincts de la note globale.
Une restauration a été exécutée, pas seulement décrite.
Les responsables, coûts et fréquences de mise à jour après projet sont financés.
Une revue des bénéfices est planifiée après la mise en service.
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.
Qu’est-ce qui distingue un projet SIG d’un projet informatique classique ?
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.
Comment rédiger un bon cahier des charges SIG ?
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.
Comment effectuer la recette d’une base géographique ?
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é.
