Les difficultés liées à l'obtention des autorisations dans le cadre des opérations sur le terrain

Tout projet d'infrastructure, quelle que soit sa complexité, nécessite des autorisations. Un permis de construire délivré par la municipalité, un permis d'excavation délivré par le service public, une autorisation environnementale, un permis d'occupation de la voie publique, parfois les quatre pour un même tronçon de route. L'autorisation n'est pas facultative : les travaux ne peuvent légalement commencer tant que l'autorisation n'a pas été obtenue, et l'inspecteur qui se présente par la suite exigera de voir les documents prouvant qu'elle a bien été obtenue.

Le problème ne réside pas dans le permis en soi. Le problème, c'est l'endroit où il se situe dans votre flux de travail. Dans la plupart des organisations, la réponse est : ailleurs. Un tableur que quelqu'un met à jour chaque semaine. Un dossier sur un disque partagé que personne ne parvient à trouver lorsque l'inspecteur le demande. Une application distincte de demande de permis que l'équipe de terrain n'utilise pas, car ce n'est pas là qu'elle effectue son travail au quotidien. Le permis devient alors un processus secondaire qui se déroule en parallèle du travail réel, auquel il n'est lié que par la mémoire et les bonnes intentions.

C'est ainsi que des permis passent inaperçus, expirent sans que personne ne s'en aperçoive ou arrivent alors que les travaux ont déjà commencé. Non pas parce que quelqu'un a fait preuve de négligence, mais parce que le permis était géré dans un système différent de celui des travaux qu'il était censé encadrer.

Quand les flux de travail parallèles échouent

La réponse habituelle à ce problème prend généralement l'une des trois formes suivantes.

Un tableur ou un document partagé. Quelqu'un tient à jour un tableau de suivi des permis : une ligne par permis, avec des colonnes pour le statut, la date d'expiration et la personne responsable. Cela fonctionne pour un petit projet. Mais cela cesse de fonctionner dès qu'il faut que plusieurs personnes le mettent à jour, dès que les permis concernent plusieurs projets, ou dès que quelqu'un demande un historique fiable indiquant qui a modifié quoi et quand. Les feuilles de calcul ne disposent pas de piste d'audit. Elles n'envoient pas de notifications lorsqu'une date approche. Elles n'empêchent pas quelqu'un de supprimer accidentellement une ligne.

Une application dédiée aux demandes de permis. Un logiciel spécialement conçu pour suivre les demandes de permis, les autorisations, les conditions et les dates d'expiration. Ces solutions existent et permettent de résoudre le problème du suivi. Ce qu'elles ne résolvent pas, c'est le problème d'intégration. Le permis se trouve dans un système. Le bon de travail en est dans un autre. L'équipe de terrain en utilise un troisième. Vous avez désormais trois endroits à vérifier, trois éléments à synchroniser, et un décalage entre eux où des erreurs peuvent se produire. Quelqu'un a-t-il commencé les travaux avant que le permis ne soit validé ? Le système de gestion des permis ne le sait pas, car il ne peut pas voir le statut de l'ordre de travail. Le permis a-t-il expiré pendant que les travaux étaient en cours ? Le système de gestion des travaux ne le sait pas, car il ne peut pas voir le statut du permis.

Confirmation par e-mail et verbale. Quelqu'un envoie un e-mail au chef d'équipe pour lui signaler que le permis a été délivré. Le chef d'équipe en informe l'équipe. Personne ne note l'heure exacte. Lorsque l'inspecteur demande des justificatifs, le chef de projet fouille dans sa boîte de réception. Ce n'est pas un système. C'est l'absence totale de système.

Chacune de ces approches engendre la même faiblesse structurelle : le permis et les travaux qu’il régit sont gérés à des niveaux différents, par des personnes différentes, sans lien automatique entre eux. Dès qu’un élément change, l’autre devient obsolète jusqu’à ce que quelqu’un pense à le mettre à jour.

Les permis en tant que tâches

Notre approche est simple : un permis est une tâche à accomplir. Il est planifié dans le cadre d'une mission, suivi sous forme d'ordre de travail, documenté par des rapports et validé selon la même chaîne de contrôle qualité que tout autre travail sur le terrain.

Une tâche représente une unité de travail planifiée — « Installer la fibre optique dans la rue Oak ». Dans le cadre de cette tâche, il peut y avoir trois ordres de travail : un pour l'obtention du permis de construire, un pour l'installation proprement dite et un pour l'inspection après installation. L'ordre de travail relatif au permis figure aux côtés de l'ordre de travail de construction au sein de la même tâche ; ils sont visibles dans la même vue du projet et font l'objet du même suivi d'avancement.

L'ordre de travail relatif au permis contient ses propres métadonnées sous forme de propriétés structurées — numéro de permis, autorité émettrice, date d'expiration, conditions, référence de la demande. Ces informations ne sont pas noyées dans un champ de description. Il s'agit de champs consultables et filtrables dans l'ordre de travail, disponibles dans les exportations et les rapports.

Le permis comporte une date d'échéance et des notifications. À l'approche de la date d'expiration, le système envoie les mêmes notifications que pour toute autre date d'échéance : résumés groupés, badges dans l'application, flux de calendrier. Il n'y a pas de système d'alerte distinct à configurer.

Le permis suit la même chaîne de validation. Une fois le permis obtenu, un rapport est soumis, accompagné du document correspondant. Un validateur vérifie qu’il s’agit bien du bon permis, pour le bon site et avec les bonnes dates. Si le permis est assorti de conditions, le validateur les consigne sous forme de remarques. Le statut de validation — validé, refusé, à réviser — détermine si les ordres de travail en aval peuvent être exécutés.

Le statut du permis est visible dans le récapitulatif du projet. Lorsqu'un chef de projet consulte la tâche, il voit l'ordre de travail relatif au permis affiché comme « terminé » ou « en attente » à côté des ordres de travail de construction. Il n'est pas nécessaire de se référer à un autre système. Si le permis n'est pas en règle, la tâche n'est pas terminée, et cela est visible d'un seul coup d'œil pour tout le monde.

Qu'en est-il des réseaux municipaux ?

Une question légitime qui revient sans cesse dans les discussions sur les permis : le logiciel devrait-il s'intégrer directement aux portails municipaux de délivrance de permis ?

Nous avons examiné la question avec attention et avons décidé de ne pas mettre ce projet en œuvre. La raison est simple : il n'existe pas de norme. Chaque municipalité gère son propre portail : des formulaires différents, des processus différents, des API différentes — quand elles en ont. Beaucoup fonctionnent encore sur papier. Mettre en place une intégration avec une seule municipalité ne profite qu'aux utilisateurs de cette municipalité, et à personne d'autre. Créer une « intégration générique pour les permis » censée fonctionner partout est une promesse impossible à tenir.

Concrètement, cela se passe ainsi : une personne se connecte au portail municipal, vérifie l'état d'avancement du permis, puis saisit les dates et les numéros de référence correspondants dans l'ordre de travail. À ce stade, le rôle du système consiste à suivre la date, à envoyer une notification à l'approche de celle-ci et à fournir une piste d'audit fiable si quelqu'un en fait la demande ultérieurement. Il ne s'agit pas d'une lacune, mais d'une reconnaissance réaliste de la frontière qui sépare votre système interne des processus administratifs externes.

La piste d'audit que les inspecteurs souhaitent réellement

Lorsqu'un inspecteur des autorités réglementaires ou un auditeur externe pose des questions sur les permis, il en pose en réalité trois : disposiez-vous du permis avant le début des travaux ? Le permis était-il valable pour le lieu et l'étendue des travaux ? Pouvez-vous le prouver ?

Lorsque le permis correspond à un ordre de travail dans le même système que les travaux de construction, les réponses sont intégrées dès le départ plutôt qu’ajoutées a posteriori :

L'ordre de travail relatif au permis comporte un historique immuable — date de création, date d'achèvement, date de validation — qui peut être comparé à la date de début de l'ordre de travail de construction. Si les travaux ont commencé avant la validation du permis, les dates le prouvent.
Le rapport de permis comprend le document de permis joint, la confirmation du validateur et toutes les conditions consignées en tant que constatations. Le rapport devient en lecture seule après validation, de sorte que les preuves ne peuvent pas être modifiées.
Les transactions d'inventaire sur les ordres de travail de construction sont horodatées et immuables. Si les matériaux ont été retirés avant que le permis ne soit validé, les horodatages des transactions de retrait QR l'indiquent.
Tout est exportable — CSV, PDF, journal d'audit — à partir d'un seul système, en une seule requête. Aucun recoupement entre des bases de données distinctes.

L'inspecteur ne se soucie pas de savoir quel module a généré la documentation. Ce qui lui importe, c'est qu'elle soit cohérente, horodatée et inviolable. Lorsque le permis et les travaux sont gérés dans un même système, cette cohérence est automatique. Lorsqu'ils sont gérés dans des systèmes distincts, elle doit être assurée manuellement.

Résumé

L'obtention d'un permis est une exigence universelle dans les travaux d'infrastructure sur le terrain, et l'erreur la plus courante n'est pas l'absence de permis, mais le suivi de ce dernier dans un système déconnecté des travaux qu'il régit.
Les tableurs, les logiciels dédiés à la gestion des permis et les confirmations par e-mail présentent tous la même faiblesse structurelle : le permis et les travaux sont gérés dans des environnements distincts, sans lien automatique entre eux.
Considérer un permis comme un ordre de travail dans le flux de travail principal signifie qu'il hérite de la même infrastructure de planification, de suivi, de validation et de piste d'audit que tout autre élément de travail — aucun processus parallèle à maintenir.
Les métadonnées spécifiques au permis — numéro de permis, autorité émettrice, date d'expiration, conditions — sont stockées sous forme de propriétés structurées dans l'ordre de travail, et peuvent être recherchées et filtrées au même titre que toutes les autres données de travail.
L'intégration du portail municipal de délivrance des permis est un problème que personne n'a encore résolu de manière générique, car il n'existe pas de norme. Le flux de travail réaliste consiste à ce qu'un opérateur saisisse les dates depuis le portail, puis que le système assure le suivi et envoie les notifications à partir de là.
La piste d'audit souhaitée par les inspecteurs — preuve que le permis a précédé les travaux, qu'il était valide pour le périmètre concerné et que la documentation est inviolable — se met naturellement en place lorsque le permis et les travaux partagent la même chronologie immuable.
Pas de module distinct à maîtriser, pas de flux de travail parallèle à gérer. La gestion des permis est intégrée de bout en bout dans le flux principal.