Vous avez traité dans WebODM.
Comment le livrer maintenant ?

En bref : WebODM écrit huit à neuf fichiers sur le disque, dont votre client peut réellement en utiliser deux. Cette page parcourt ce que WebODM a produit exactement, quels fichiers ont leur place dans une livraison, comment les rendre ouvrables par quelqu'un sans logiciel SIG, et comment remettre l'ensemble sous forme d'une seule adresse plutôt que de six pièces jointes.

Le problème n'est pas le traitement. Ce sont les 10 derniers mètres.

Votre tâche est terminée. Le tableau de bord WebODM est au vert, vous vous déplacez dans une orthophoto impeccable, il y a un nuage de points et un modèle texturé. Cela ressemble à du travail fini. Ce n'est pas livré.

Tout ce que vous voyez vit à l'adresse http://localhost:8000 — une adresse qui n'existe que sur la machine ayant fait le traitement. Votre client ne peut pas y accéder. Ni depuis son bureau, ni depuis son téléphone, ni demain. Dès que quelqu'un d'autre doit voir ce résultat, vous devez décider ce qui quitte votre ordinateur, sous quelle forme, et comment il l'ouvrira.

Cette décision est le travail, et c'est précisément là que tout déraille : le pilote compresse le dossier de sortie, dépose 4 Go sur WeTransfer et appelle ça une livraison.

Étape 1 — Savoir ce que WebODM a réellement écrit

Ouvrez votre tâche terminée et utilisez Download Assets. Ce menu déroulant est la carte de tout ce que le traitement a produit. Sur le disque, ces mêmes fichiers se trouvent dans le dossier du projet, dans ces sous-dossiers :

Les tailles sont des ordres de grandeur pour une mission typique de 200 à 800 images et évoluent avec votre GSD. Les noms de dossiers proviennent de la structure de sortie d'OpenDroneMap ; si vous utilisez une autre version de WebODM, ouvrez Download Assets et confrontez la liste à ce tableau avant de vous y fier.

Étape 2 — Déterminer à qui s'adresse chaque fichier

Trois personnes différentes attendent trois choses différentes de la même tâche, et les confondre est l'erreur de livraison la plus fréquente :

• Le client qui a commandé le vol. Veut voir le site, comprendre ce que vous avez trouvé et pouvoir le montrer à quelqu'un d'autre. A besoin d'une visionneuse et d'un rapport. N'a pas de logiciel SIG et n'en aura jamais.
• Le géomètre, l'architecte ou le bureau d'études qui suit. Veut des données géoréférencées exploitables : l'orthophoto en GeoTIFF, le MNS, parfois le nuage de points. A besoin du système de coordonnées énoncé explicitement.
• Vous-même, dans dix-huit mois. Voulez la sortie complète plus les paramètres de traitement, pour qu'un vol de comparaison soit exploitable. Ça, c'est une archive, pas une livraison.

Envoyer all.zip à la première personne n'est pas de la générosité, c'est lui refiler votre travail. Elle l'ouvrira, y trouvera un .laz illisible pour elle, et vous écrira pour demander quoi en faire.

Étape 3 — Rendre l'orthophoto ouvrable par un humain

Un GeoTIFF de 3 Go est un fichier de travail, pas une livraison. La visionneuse de photos de Windows ne l'ouvrira pas. Il a trois destinations réalistes, et vous en voulez souvent plus d'une :

1. La garder interactive. La version que votre client veut vraiment est celle où il peut se déplacer et zoomer, exactement comme vous dans l'onglet carte de WebODM. Cela signifie servir des tuiles, pas envoyer un fichier — voir l'étape 5.
2. Un Cloud Optimized GeoTIFF pour le destinataire technique. Un COG se diffuse en continu au lieu de se télécharger en entier, si bien que QGIS l'ouvre sans vingt minutes d'attente :

   gdal_translate -of COG -co COMPRESS=DEFLATE \
     odm_orthophoto.tif ortho_cog.tif

3. Une image plate pour tous les autres. Un JPEG ou PNG réduit qui s'ouvre sur n'importe quel téléphone, pour l'e-mail, la couverture du rapport, la réunion de chantier :

   gdal_translate -of JPEG -outsize 4000 0 -co QUALITY=88 \
     odm_orthophoto.tif ortho_preview.jpg

Quoi que vous envoyiez, indiquez par écrit le système de coordonnées (le code EPSG) et le GSD en cm/pixel. Un GeoTIFF sans système annoncé est une photo, pas un produit de mesure, et le destinataire n'a aucun moyen de vérifier vos hypothèses.

Étape 4 — Décider du sort du nuage de points et du modèle 3D

Le nuage de points. odm_georeferenced_model.laz est ce que WebODM produit de plus brut et n'a presque jamais sa place dans une livraison client. Si un géomètre l'a expressément demandé, envoyez le LAZ accompagné de trois précisions écrites : le code EPSG, le référentiel altimétrique, et si le nuage est classifié. Sans cela il est inexploitable et vous reviendra directement.

Le modèle texturé. L'OBJ est en réalité trois éléments qui doivent rester ensemble : le .obj, son .mtl, et les images de texture. Envoyez-en un sans les autres et votre client ouvrira une masse grise sans texture. Pour tout usage web, convertissez d'abord en glTF/GLB, ou publiez le modèle dans une visionneuse et livrez l'intégration plutôt que la géométrie.

La règle générale : si ouvrir un fichier exige un logiciel que votre client n'a pas, vous n'avez pas livré un résultat — vous avez délégué un problème.

Étape 5 — Le piège : le lien de partage de WebODM

WebODM peut rendre une tâche publique et vous donner une URL vers ses vues carte et 3D. À première vue cela règle tout. Deux points déterminent si c'est vrai :

• Une installation locale n'est pas joignable. Si WebODM tourne dans Docker sur votre propre machine, le lien public pointe vers localhost ou une adresse du réseau local. Il fonctionne parfaitement sur votre écran et pas du tout sur celui de votre client. C'est de loin la raison la plus fréquente pour laquelle un lien WebODM « partagé » arrive mort.
• Exposer l'instance est une décision, pas un détail. La rendre joignable depuis Internet revient à mettre votre serveur de traitement en ligne, avec les tâches de vos autres clients dessus. C'est d'abord une question de sécurité et de confidentialité, et seulement ensuite une question de confort.

WebODM Lightning règle le premier point — c'est hébergé, donc un lien de tâche public s'ouvre réellement pour tout le monde. Il ne règle pas la seconde moitié du travail : le rapport, les photos et le contexte restent ailleurs, et votre client se retrouve encore avec plusieurs liens.

Étape 6 — Regrouper le tout en une seule livraison

À ce stade vos choix sont faits : une visionneuse pour la carte, éventuellement un modèle 3D, un rapport PDF, une sélection de photos, peut-être un GeoTIFF pour le destinataire technique. La dernière étape consiste à transformer cet ensemble en une seule adresse que votre client peut ouvrir, comprendre et retrouver.

C'est la couche que couvre DronePortal. Aucun traitement n'y est fait — WebODM reste votre moteur, et rien ne change à votre façon de travailler. Ce qu'il fait, c'est tenir la livraison ensemble :

• La carte interactive ou la vue 3D intégrée dans la page, pour que le déplacement et le zoom fonctionnent là où le client se trouve déjà
• Le rapport qualité, les photos et les éventuels téléchargements juste à côté, pas dans un e-mail séparé
• Un code d'accès par projet au lieu d'un lien par fichier
• Une adresse qui répondra encore l'an prochain, quand un lien WeTransfer sera mort depuis sept jours

L'ordre compte : les étapes 1 à 5 sont le vrai travail, et elles restent identiques que vous utilisiez quelque chose de chez nous ou non. L'étape 6 ne concerne que la manière dont cela arrive.

En pratique : les clics réels

1. Obtenez d'abord une URL de visionneuse publique. Pour WebODM il y a deux voies. Sur WebODM Lightning, partagez la tâche et copiez le lien public — cette URL est déjà joignable et s'intègre telle quelle. Sur un WebODM auto-hébergé cela ne fonctionne pas (étape 5) : publiez plutôt le modèle texturé vers une visionneuse intégrable comme Sketchfab ou Polycam, et utilisez ce lien. Pour l'orthophoto, il vous faut une visionneuse cartographique tuilée, jamais le GeoTIFF brut — un fichier de 3 Go n'est pas quelque chose qu'un iframe peut afficher.
2. Collez l'URL de page ordinaire ; elle est convertie à l'enregistrement. Une page de modèle Sketchfab, un lien Matterport /models/, un lien Kuula /post/ et une page de capture Polycam refusent tous les quatre d'être intégrés tels quels. DronePortal les réécrit vers leur forme d'intégration au moment de l'enregistrement : vous n'avez pas à chercher le code d'intégration. Une exception : les liens courts skfb.ly sont refusés avec un message — collez l'URL Sketchfab complète.
3. Tableau de bord → « + Nouveau projet ». Choisissez un client existant ou saisissez directement un nom et un e-mail dans le formulaire. Donnez un nom et un type au projet, puis nommez la première unité. À l'enregistrement, DronePortal crée le client, le projet et l'unité, génère un code d'accès de 8 caractères et vous place aussitôt dans l'écran d'édition de cette unité.
4. Section 🗺 Viewers — une ligne par visionneuse. Choisissez le type (3D Visuel, 3D Thermique, 2D Carte, Visite 360°), écrivez un libellé que votre client lira, et collez l'URL. Pour WebODM : l'orthophoto sous 2D Carte, le modèle texturé sous 3D Visuel. « + Ajouter un viewer » pour la suivante. En dessous, choisissez le Viewer principal — celui qui s'ouvre en premier — ou laissez « Automatique (premier viewer) ».
5. Section 📋 Documents & médias — ajoutez le rapport. « + Ajouter un document ou un lien », réglez le type sur Fichier et utilisez « ↑ Envoyer » pour le PDF du rapport qualité WebODM (pdf, jpg et png sont acceptés). Le type Lien pointe vers quelque chose hébergé ailleurs. Les champs de libellé NL/FR/EN sont le texte du bouton que votre client voit : remplissez au moins la langue de cette livraison.
6. Section 📷 Photos — envoyez la sélection. Thermique, visuel et zoom. C'est une sélection, pas un déversement : ce sont les images qui portent vos constats, pas la carte entière.
7. Section Portail — ouvrez l'accès. Passez le statut sur Actif, choisissez la langue, renseignez la date de prise de vue et, si la mission l'exige, une date d'expiration. Le code d'accès se trouve dans cette même section.
8. Transmettez un seul lien. L'URL client est https://{votre-sous-domaine}.droneportal.app/app/portaal/?code={CODEDACCES}. Une adresse et un code — aucun compte pour votre client, rien à installer.

Ouvrez ce lien vous-même en navigation privée avant de l'envoyer. C'est le seul moyen de voir ce que votre client voit plutôt que ce que votre session connectée affiche.

Avant d'envoyer : une check-list

• Date de vol et GSD indiqués par écrit
• Code EPSG précisé pour chaque fichier géoréférencé
• Chaque fichier s'ouvre sans logiciel spécialisé — ou est explicitement signalé comme destiné au géomètre
• Le .obj, le .mtl et les textures du modèle 3D voyagent ensemble
• Vous avez ouvert la livraison vous-même sur un téléphone, hors de votre propre réseau
• Rien ne pointe vers localhost ni vers une adresse IP interne
• Il est clair ce qui n'est pas inclus, pour que personne ne l'attende
• Il existe un chemin de retour opérationnel vers vous pour les questions

Cinq façons de rater une livraison WebODM

1. Envoyer all.zip. Tout, et donc rien. Le client ne peut pas distinguer ce qui compte.
2. Un GeoTIFF brut par WeTransfer. Trop lourd à télécharger, impossible à ouvrir, disparu au bout de sept jours.
3. Un lien de partage vers une instance locale. Ne fonctionne que sur votre machine. Vous ne l'apprendrez que par le client.
4. Aucun système de coordonnées. Rend invérifiable chaque fichier géoréférencé de la livraison.
5. Six liens dans trois e-mails. Techniquement complet, pratiquement perdu dès la deuxième semaine.

Même démarche pour d'autres outils : livrer un projet Pix4D · livrer une reconstruction DJI Terra. À lire aussi : traiter en local, livrer professionnellement et votre client ne voit jamais votre nuage de points.

Questions fréquentes

À lire aussi

• Qu’est-ce qu’un portail client pour drone ?
• Arrêtez d’envoyer des liens WeTransfer à vos clients

Prêt à vous lancer ?

Testez l'étape 6 sur votre prochain projet WebODM

Les étapes 1 à 5 ne changent pas. Essai gratuit, sans carte de crédit.