Logiciel SIG ou DAO pour vos projets de topographie

C’est précisément là que beaucoup de flux de travail se grippent: le levé GNSS est propre, les points semblent cohérents, puis le plan ne recale plus avec le fond de référence, la plateforme SIG ou le modèle de projet. On cherche un bug logiciel; le problème est souvent dans la chaîne, entre les usages, les formats et le système de coordonnées.

Le débat « logiciel SIG vs DAO pour topographie » est donc mal posé lorsqu’il devient une opposition de chapelles. Sur un chantier, au cabinet ou dans un service technique, nous n’achetons pas un acronyme. Nous devons faire circuler une donnée sans la déformer: depuis le point mesuré et codé sur le terrain jusqu’au plan, à la surface de projet, à la carte de synthèse ou à la base patrimoniale.

Le SIG et la DAO répondent à des logiques différentes. Les confondre crée de la friction. Les articuler, en revanche, donne une équipe plus fluide et des livrables qui tiennent la route.

Le bon outil n’est pas celui qui ouvre le fichier: c’est celui qui préserve le sens de la donnée au moment où elle doit être utilisée.

SIG et DAO: deux manières de regarder la même emprise

La différence entre SIG et CAO en topographie ne se résume pas à « la carte d’un côté, le dessin de l’autre ». Elle se situe dans la structure même de l’information.

Un logiciel SIG organise des couches géoréférencées, leurs attributs et leurs relations. Une canalisation n’est pas seulement un trait: elle peut porter un diamètre, un matériau, une date de pose, un gestionnaire, un état, une photographie ou un identifiant d’intervention. L’enjeu est de retrouver, croiser, filtrer, mettre à jour et partager ces objets à l’échelle d’un territoire ou d’un parc d’actifs.

La DAO, et plus particulièrement les environnements de topographie et de génie civil, part davantage de la géométrie de projet. Nous y travaillons les points, les lignes de rupture, les limites, les profils, les plateformes et les surfaces. Elle est dans son élément lorsqu’il faut produire un plan d’exécution, préparer une implantation, calculer des volumes ou contrôler la cohérence géométrique d’un projet.

Prenons un relevé de mobilier urbain. Si l’objectif est de créer un inventaire de candélabres, d’arbres, de tampons ou de bornes, avec leurs caractéristiques et leur historique, le SIG prend l’avantage. L’équipe terrain collecte une position, un code, des attributs, éventuellement une photo. Le bureau obtient une base exploitable dans le temps, pas une succession de calques figés.

À l’inverse, pour reprendre un terrain avant terrassement, construire un modèle de surface, intégrer des lignes de rupture puis comparer des déblais-remblais, la DAO métier est plus naturelle. Dans Civil 3D, par exemple, une surface peut être construite à partir de points, de lignes de rupture, de limites et de courbes de niveau. Les surfaces TIN, sur grille ou de volume répondent à des usages de conception bien identifiés.

Le compromis réaliste est souvent simple: la DAO produit et contrôle la géométrie de chantier; le SIG diffuse, enrichit et remet cette géométrie dans son contexte territorial. Ce n’est pas du doublon. C’est une répartition du travail.

Le format de fichier n’est pas un détail de fin de chaîne

Le fichier qui « s’ouvre » n’est pas forcément le fichier qui reste exploitable. C’est l’une des leçons les plus coûteuses de la compatibilité données SIG et DAO.

QGIS, par exemple, sait lire de nombreuses sources vectorielles: GeoPackage, Shapefile, DXF, PostGIS ou SpatiaLite. Mais la lecture ne garantit pas que toutes les géométries, tous les attributs, tous les styles ou tous les objets métier seront conservés à l’identique. Selon le pilote et le format, une conversion de géométrie peut intervenir. C’est discret à l’écran, beaucoup moins discret lorsque la donnée revient dans l’outil source.

Le DXF reste très utile pour échanger un dessin. Il peut être ASCII ou binaire; ce dernier réduit l’espace disque nécessaire d’environ 25 % selon la documentation Autodesk. Mais il faut être lucide: le DXF est un format d’échange de dessin, pas une promesse de continuité fonctionnelle.

Lors d’un export d’objets métier AEC vers DWG ou DXF, certains éléments peuvent être éclatés en primitives AutoCAD: lignes, arcs, faces 3D. La géométrie reste visible, mais l’intelligence métier peut disparaître. Une surface, une figure codée ou un objet paramétrique ne revient pas automatiquement à la vie une fois réimporté. C’est un peu comme envoyer un plan plié dans une enveloppe trop petite: il arrive, mais pas forcément avec tous ses plis d’origine.

Pour un échange SIG durable, le GeoPackage mérite une place centrale dans la discussion. Le standard OGC GeoPackage 1.4.0 repose sur un conteneur SQLite. Il peut embarquer des entités vectorielles, des tuiles d’images ou raster, ainsi que des tables non spatiales. Lorsqu’il reste conforme au standard, sans extension propriétaire, il facilite réellement l’interopérabilité entre environnements.

Voici une règle qui évite bien des retours de balle entre le terrain, le bureau d’études et le maître d’ouvrage:

1. Conservez le fichier natif comme source de vérité. Un dessin DAO reste dans son environnement de conception; une base SIG reste dans son environnement de gestion. L’export est un livrable ou une passerelle, pas forcément l’archive de référence.

2. Définissez le niveau d’échange attendu avant l’export. Faut-il une image de plan, des polylignes éditables, des attributs complets, des points cotés, une surface, ou une base de données interrogeable? Un seul « DXF demandé » ne répond à aucune de ces questions.

3. Testez sur un échantillon qui a du relief. Un point, une polyligne et un texte passent presque toujours. Il faut aussi tester les blocs, les calques, les attributs, les courbes, les objets 3D et les codes terrain qui font la vraie vie d’un dossier.

4. Documentez ce qui est perdu ou figé. Ce n’est pas un aveu d’échec. C’est une consigne de reprise claire pour l’équipe suivante.

Les services WMS illustrent une autre confusion fréquente. Un WMS fournit, via HTTP, une image cartographique géoréférencée — souvent en PNG ou JPEG — issue d’une ou plusieurs bases géospatiales. On peut superposer plusieurs couches provenant de serveurs différents. C’est très précieux pour contextualiser un levé: cadastre, orthophoto, zonage, réseau public.

Mais une image WMS n’est ni une couche vectorielle éditable, ni un levé brut. Elle sert de fond, de référence visuelle ou de support de consultation. Lui demander de remplacer la donnée vectorielle revient à vouloir implanter avec une capture d’écran: on voit l’intention, on n’a pas la matière.

Avant le logiciel, le référentiel: RGF93, projection et altitude

Dans les projets français, l’erreur qui coûte du temps n’est pas toujours une mauvaise manipulation. C’est souvent une information absente dans le fichier: quel système horizontal? quelle projection? quel référentiel vertical? quelle transformation a été appliquée?

Le RGF93 est le référentiel géodésique français adapté aux techniques modernes de positionnement. Il est associé à Lambert-93 et aux projections coniques conformes CC à neuf zones. Pour la France métropolitaine, Lambert-93 correspond au code EPSG:2154. Ce repère est familier, mais il ne dispense jamais de lire le contexte du projet.

Le RGF93v2b a remplacé le RGF93(v2) le 5 janvier 2021. Il est aligné sur l’ETRF2000 à l’époque 2019.0. L’IGN associe notamment à cette réalisation les grilles de conversion altimétriques RAF20 et RAC23. Ces éléments peuvent sembler très académiques tant qu’un fichier ne quitte pas le bureau. Dès qu’il passe d’un contrôleur GNSS à une DAO, puis à un SIG, ils deviennent concrets.

L’IGN annonce pour le RGF93 une exactitude de l’ordre de 1 à 2 cm en horizontal et de 2 à 5 cm en vertical par rapport aux systèmes mondiaux. Il ne faut pas transformer cette donnée en promesse de précision finale pour chaque levé GNSS. La précision opérationnelle dépend du mode de mesure, de la réception satellitaire, de l’instrument, du contrôle, du canevas, de l’environnement et du cahier des charges. Nous le savons tous sur le terrain: sous couvert végétal, au pied d’une façade ou dans une rue encaissée, l’écran peut être rassurant sans que la situation le soit.

Une coordonnée sans référentiel documenté est une coordonnée qui finira par faire discuter deux équipes au mauvais moment.

Dans un flux de travail topographie SIG, la bonne pratique consiste à faire voyager ces informations avec les données, pas dans la tête d’une seule personne:

• le système de coordonnées du levé et celui du livrable;
• la projection employée sur la zone concernée;
• le référentiel altimétrique et, le cas échéant, la grille de transformation;
• l’unité des coordonnées et des altitudes;
• la date, la méthode de levé et les contrôles réalisés;
• la convention de nommage des points et des codes.

Cette discipline paraît modeste. Elle réduit pourtant fortement la courbe d’apprentissage quand un nouveau collaborateur reprend le dossier, et elle évite la fameuse phrase: « Chez moi, ça tombe à côté. »

Du fichier PENZ à la surface: le flux doit suivre l’usage

Le choix d’un logiciel de traitement de données géospatiales se joue souvent dans les vingt premières minutes après le retour terrain. C’est là que l’on décide, parfois sans le dire, si les données deviennent un modèle fiable ou une pile de fichiers à recoller.

Dans un environnement topographique, l’import de points reste un moment sensible. Un fichier texte de type PENZ peut contenir, dans cet ordre, le numéro de point, l’est X, le nord Y et l’altitude Z. L’ordre des colonnes doit correspondre au format défini à l’import. Cela paraît élémentaire; c’est pourtant l’une des frictions les plus ordinaires entre les habitudes de terrain, les exports de contrôleur et les gabarits du bureau.

Une inversion X/Y ne produit pas toujours une alerte spectaculaire. Elle peut créer une donnée absurdement éloignée, une emprise inversée ou une surface incohérente. Le logiciel fait alors exactement ce qu’on lui a demandé, pas ce que nous pensions lui demander.

Dans Civil 3D, les données de levé sont stockées dans une base externe indépendante du dessin. Elle peut contenir des points de contrôle, des directions connues, des observations, des cheminements, des figures et les écarts-types liés aux équipements. Cette séparation est particulièrement intéressante lorsqu’une équipe reprend plusieurs fois une même zone ou doit conserver la traçabilité entre calcul de levé et production graphique.

Le flux de travail efficace ressemble moins à une ligne droite qu’à une boucle maîtrisée:

1. Au terrain, codifier pour l’usage futur. Les codes ne doivent pas être conçus uniquement pour accélérer la saisie. Ils doivent permettre au bureau de reconnaître une limite, une rupture, un fil d’eau, un mobilier, une végétation ou un point de contrôle sans interprétation hasardeuse.

2. Au retour, contrôler avant de dessiner. Vérifier l’emprise, les altitudes atypiques, les doublons, les points isolés et la cohérence avec les repères connus. Un contrôle rapide ici évite de construire une belle surface sur une erreur banale.

3. Dans la DAO, construire le modèle de projet. Les points ne suffisent pas pour représenter le terrain. Les lignes de rupture et les limites donnent son comportement au modèle TIN; elles doivent être posées avec le jugement du topographe, pas générées à l’aveugle.

4. Dans le SIG, enrichir et partager. Une fois les objets stabilisés, ils peuvent rejoindre une couche structurée avec les attributs nécessaires: nature, date, équipe, précision attendue, état de validation, lien avec une opération.

5. Prévoir le retour d’information. Si le SIG révèle une incohérence patrimoniale ou une modification de terrain, la correction doit pouvoir revenir vers le flux topographique avec une responsabilité claire.

Ce dernier point est humain avant d’être technique. Une équipe adopte un nouvel outil lorsqu’elle voit ce qu’il lui fait gagner dans son quotidien: moins de ressaisie, moins d’ambiguïtés, moins de fichiers qui circulent sans propriétaire. Si le SIG est vécu comme une couche administrative ajoutée au-dessus du chantier, l’adoption patinera. Si la DAO est perçue comme une boîte noire réservée à une personne, le même problème apparaîtra de l’autre côté.

Choisir sans fabriquer une usine à gaz

Il n’existe pas de logiciel universellement meilleur pour un cabinet de géomètres, une collectivité ou une entreprise de travaux publics. Les licences, les fonctions de saisie hors ligne, les capacités GNSS, les corrections temps réel et les exports métier varient selon les produits. La bonne décision part donc du travail réel, pas d’un catalogue de fonctions.

Pour choisir un logiciel SIG pour levé terrain, nous pouvons nous poser quelques questions très concrètes.

Le projet produit-il d’abord des livrables de conception — plans, profils, cubatures, plateformes, implantations? La DAO topographique doit alors rester le cœur du dispositif. Un SIG peut compléter l’ensemble pour la consultation, le suivi et la diffusion, mais il ne faut pas lui demander de porter seul une logique de conception complexe.

Le projet vise-t-il un inventaire pérenne d’équipements ou de réseaux, régulièrement mis à jour par plusieurs équipes? Le SIG devient le point de gravité. Les géométries issues du levé sont essentielles, mais leur valeur vient aussi des attributs, des droits d’accès, de la recherche et de l’historique.

Faut-il travailler avec des donneurs d’ordre qui demandent des bases interopérables? Dans ce cas, il est judicieux d’intégrer dès le départ des formats ouverts comme le GeoPackage, plutôt que de tout reporter sur une conversion finale. Ce choix ne résout pas tous les écarts entre applications, mais il réduit la dépendance à un environnement propriétaire pour les couches SIG standards.

Enfin, qui va réellement utiliser l’outil lundi matin? Le conducteur de travaux n’a pas le même besoin que le projeteur, le technicien de terrain ou le gestionnaire de patrimoine. L’ergonomie, les modèles de saisie, le vocabulaire des formulaires et l’accès aux fonds de plan comptent autant que la puissance théorique du logiciel. Sur ce point, le meilleur compromis est souvent celui qui laisse les gens travailler sans les forcer à contourner le système.

La conversion n’est pas une traduction parfaite

Nous avons tous reçu ce fameux fichier « compatible » qui ouvre correctement, mais dont les calques sont désordonnés, les attributs absents ou les objets métier réduits à des lignes. Ce n’est pas forcément la faute de la personne qui a exporté. C’est la limite normale d’un passage entre des modèles de données différents.

Le SIG raisonne par couches, tables, relations et référentiels. La DAO raisonne par entités graphiques, règles de dessin et objets de projet. Entre les deux, il faut décider ce qui doit être préservé en priorité.

Pour un plan de consultation, la fidélité visuelle peut suffire. Pour une reprise de conception, il faut préserver la structure DAO native autant que possible. Pour un inventaire, les attributs et les identifiants priment sur la sophistication graphique. Pour un modèle de terrain, les points, les lignes de rupture, les limites et le référentiel sont le socle; une belle symbologie ne compensera jamais leur perte.

Cette hiérarchie doit être écrite dans la convention d’échange. Pas dans un mail envoyé à la veille du rendu, pas dans les habitudes d’un seul collaborateur. Une page claire sur les formats, les systèmes de coordonnées, les règles de nommage et les objets attendus suffit souvent à fluidifier toute la chaîne.

La technologie ne remplace pas le dialogue entre le terrain, le dessin et la donnée. Elle le rend simplement plus exigeant. Un SIG bien intégré ne transforme pas les topographes en administrateurs de bases; il leur évite de remesurer, de ressaisir et d’expliquer trois fois ce qu’un point voulait dire. Une DAO bien cadrée ne réduit pas les données à un dessin; elle donne à la géométrie la rigueur nécessaire pour devenir une décision de chantier.

Choisir entre SIG et DAO n’est donc pas choisir un camp. C’est organiser le passage de relais. Quand le référentiel est clair, que les formats sont choisis pour leur usage et que chaque équipe sait ce qu’elle reçoit comme ce qu’elle doit restituer, la donnée circule enfin sans mettre de cailloux dans les chaussures du projet.