QGIS 4.2, Qt 6. Opérateur fibre.
VTT
Visite technique sur le canevas QGIS.
Préparer une visite fibre passe par PostgreSQL, des tableurs, des KML et des tablettes. Plusieurs personnes planifient en parallèle. VTT regroupe ce cycle dans un plugin QGIS.
v1.0.0 du 21/10/2026, statut experimental. La recette terrain reste ouverte.
Vérifiés dans le dépôt.
01/10 au 21/10
Dépôt créé, puis v1.0.0
18
Commits Git
81
Tickets avec critères de sortie
Géométrie synthétique
Chargement de la scène
Deux tracés pour un même tronçon multi-SRO. Le doublon est visible.
- Transport
- Distribution
- Tronçon partagé
- Doublon
- Tournée
- Anomalie
01
Données dispersées
Sur un déploiement FTTH, chaque tronçon d’étude est visité, documenté, puis réconcilié avec la base. Le stock d’étude est dans PostGIS. Le planning est dans des fichiers. Les retours arrivent par e-mail ou par clé USB. Les contacts des gestionnaires sont vérifiés à la main.
Un doublon de tronçon se traite à la main, un conflit de planning aussi. Un retour peut se perdre. Sur la scène, un tronçon multi-SRO est dessiné deux fois. Après déduplication, il ne reste qu’une géométrie.
02
Cycle sur le canevas
Le plugin enchaîne le pilotage, la préparation, les retours et la zone suivante. L’étape choisie met la scène à jour.
Pilotage
Filtres par SRO, état, type et date. Listes virtualisées. Un tronçon rattaché à plusieurs SRO est dédupliqué. La fiche contient l’historique, les contacts et les annotations. La saisie par lot est tout ou rien.
Préparation
Nommage automatique des tournées, calendrier partagé entre préparateurs, météo du secteur de 8 h à 18 h. Le plugin produit le tableau de départ, les contacts, le KML et un projet QField hors ligne. Les routes et voies ferrées IGN qui croisent les zones sont embarquées. L’envoi USB a un repli en archive ZIP vérifiée.
Retours
La reprise est simulée avant toute écriture. Un sas d’intégration reçoit les retours QField, avec déclaration de couverture. Une anomalie se tranche avec un auteur et une justification.
Recommandations
Le plugin propose la zone suivante. Le routage local fonctionne hors ligne. Six graphiques suivent l’avancement. Le journal d’équipe envoie les notifications.
03
Règles de calcul
Les décisions métier sont écrites avant le code. Un registre, DECISIONS.md, trace chaque choix provisoire : lecture du CCTP, règles d’éligibilité.
Un historique non certifié ne produit pas de courbe fictive. Une population non homologuée ne produit pas de taux présenté comme validé.
« Un chiffre affiché, un chiffre exporté et un chiffre contrôlé en recette sortent de la même fonction. »
Passer sur un historique non certifié. Affichage, export et recette restent sur le même résultat.
Affiché
Exporté
Recette
Les barres sont un schéma. Affichage, export et recette lisent la même série.
04
Séparation des modules
compat.py est le seul module qui appelle Qt 6.
- domaine/Règles métier, sans Qt
- donnees/PostGIS, imports, sas
- services/Cas d’usage, exports, QField
- controleurs/Orchestration
- modeles/Modèles présentés à l’interface
- taches/Tâches de fond
- QMLInterface dessinée sur la carte
- compat.pySeul appel à Qt 6
- Migrations SQL versionnées.
- Cinq rôles PostgreSQL, sans connexion propre.
- Lectures en REPEATABLE READ READ ONLY. Pagination par valeur.
- Aucun secret écrit par le plugin. Aucune télémétrie externe.
- Le diagnostic local ne garde que des codes et des mesures.
05
Ce qui est vérifié
Les chiffres ci-dessous viennent du dépôt. Les autres points sont nommés, sans valeur.
01/10 au 21/10
Dépôt créé, puis v1.0.0
2026. Trois semaines de calendrier entre la création du dépôt et la version.
18
Commits Git
L’import initial, en v0.3.1, date du 05/10/2026.
81
Tickets avec critères de sortie
La clôture d’un lot passe par ses critères de sortie.
50
Cycles montage, rendu, démontage
Vérifiés dans le moteur natif QGIS 4.
6
Graphiques de suivi
experimental
Statut de la v1.0.0
La recette terrain est encore ouverte : appareil QField cible, formulaire Kizeo, PV opérateur.
Banc isolé
PostgreSQL
Transactions, droits, concurrence, réimports, restauration.
Non publié
Aucun chiffre n’est affiché pour ces points tant qu’ils ne sont pas confirmés.
En attente de confirmation
Volumes repris sur la base de l’opérateur
Des volumes sont dans le dépôt. Ils ne sont pas cités ici tant que leur publication n’est pas accordée.
En attente de confirmation
Gains mesurés, adoption, retours d’usage
Aucun temps gagné, aucun effectif et aucun retour chiffré n’est publié dans le dépôt.
En attente de confirmation
Distinction
Aucune récompense n’est documentée.
En attente de confirmation
Citation d’un utilisateur
Pas de citation validée, même anonyme.
En attente de confirmation
Mise en production
La v1.0.0 est marquée experimental. Aucun passage en production n’est documenté.
En attente de confirmation
Prototype antérieur au 01/10/2026
Le Git commence le 01/10, avec un import v0.3.1 le 05/10. L’absence de prototype avant cette date n’est pas confirmée.
Journal de construction
1 oct. 2026
Dépôt créé, premières décisions
5 oct. 2026
Import v0.3.1
12 oct. 2026
Migrations 140/150 sur la base de l’opérateur
21 oct. 2026
v1.0.0
Jalons datés du journal de construction. Les 18 commits Git ne sont pas listés un par un.
Entre le 01/10/2026 et la v1.0.0, les objets métier étaient déjà nommés : SRO, GC, CCTP, retours QField. Les décisions sont écrites avant le code.
Même type de cycle sur un autre réseau.
Le diagnostic décisionnel fixe un périmètre fermé. Le contact se fait par e-mail.
L’autre étude: RecoverLand