Logiciel de gestion de copropriété : de la panne au sous-sol à l'ordre de travail clôturé

Dimanche soir. Un résident du bâtiment B remarque que la porte du parking au sous-sol ne se ferme pas. Autrefois, cette information tombait dans un groupe de messagerie, on attendait que quelqu'un la voie, et personne ne savait qui s'en occuperait. Sans enregistrement, il n'y avait pas non plus de responsable ; quant à la fin du travail, c'était le plus souvent la réclamation suivante qui la signalait.

Dans le Logiciel de gestion de copropriété, la même panne devient un enregistrement suivi de son ouverture à sa clôture. Cet article décrit le flux qui va de la demande à l'ordre de travail, puis jusqu'au téléphone du technicien.

Le projet en bref

Le Logiciel de gestion de copropriété est la plateforme opérationnelle que nous avons développée pour un client qui gère de nombreux projets résidentiels et mixtes au sein d'une même structure d'entreprise. Elle se compose d'un panneau d'administration web et d'applications mobiles pour les résidents, le terrain et les gestionnaires. La gestion des demandes et des réclamations a été mise en production lors de la première phase, les pannes, la maintenance, les ordres de travail et le mobile terrain lors de la deuxième. Les modules de finances et de charges, de réservation, de visiteurs, d'inventaire et de compteurs partagent le même socle de données.

Dès l'ouverture de la demande, l'horloge se met à tourner

Le résident ouvre la demande depuis l'application mobile ou le web : il choisit une catégorie et une sous-catégorie, rédige une description, joint une photo ou une vidéo, et précise l'urgence et la localisation. La localisation est sélectionnée, autant que possible, parmi les résidences, bâtiments, lots et espaces définis dans le système plutôt qu'en texte libre. Ce détail prendra bientôt de l'importance.

Chaque catégorie de demande a son propre délai SLA. À l'ouverture de la demande, le système calcule l'heure cible de clôture, génère une alerte avant l'échéance et, en cas de retard, marque l'enregistrement comme un manquement. Le tableau de bord SLA présente dans une seule liste les groupes « en retard », « en alerte » et « dans les délais » ; la gestion voit d'un coup d'œil quel travail est à risque.

La demande progresse parmi les statuts nouvelle, en cours de traitement, en attente, résolue ou annulée. Les changements de statut sont soumis à un contrôle d'autorisation et chaque modification est envoyée au résident sous forme de notification ; côté résident, les statuts techniques intermédiaires sont affichés de façon simplifiée. Les notifications sont transmises par SMS, e-mail ou notification push selon la préférence de canal de l'utilisateur ; les changements de statut critiques sont toujours acheminés par au moins un canal.

Une règle simple qui trouve la bonne équipe

Ce sont les règles d'acheminement définies dans le panneau qui décident à qui revient la demande. Nous avons volontairement gardé ces règles simples : la cible est soit une équipe, soit une personne, et c'est la précision de la localisation et l'ordre des règles qui déterminent la correspondance. On essaie d'abord l'espace, puis le lot, puis le bâtiment, puis la résidence et, en dernier, la règle générale ; parmi les règles du même niveau, celle dont l'ordre vient en premier l'emporte. Si l'équipe cible est vide, la règle est ignorée ; si aucune règle ne convient, la demande tombe dans la liste des demandes non affectées et le gestionnaire l'affecte à la main. Lorsqu'une personne est choisie au sein d'une équipe, c'est le membre qui a le moins de travaux ouverts qui est mis en avant.

Une seule autorisation ne suffit pas non plus pour prendre en charge une demande : l'autorisation de prise en charge, l'appartenance à l'équipe de demandes de cette résidence et le rattachement à la résidence sont exigés ensemble. Les équipes de demandes et les équipes d'intervention sont tenues séparées ; un même technicien peut figurer dans les deux, mais l'appartenance à une équipe n'ouvre pas la porte à la file de l'autre.

L'ordre de travail dans la poche du technicien

Lorsque la panne devient un ordre de travail, le volet maintenance de la deuxième phase entre en jeu. Le numéro de l'ordre de travail, sa catégorie, l'équipe ou la personne affectée, ses durées planifiée et réalisée se trouvent dans le même enregistrement ; la priorité est l'un des niveaux faible, moyenne, élevée et critique. Les maintenances planifiées sont, elles, rattachées à un calendrier au moyen de modèles et de listes de contrôle ; la périodicité peut être quotidienne, hebdomadaire ou mensuelle, et les maintenances en retard sont marquées de façon visible. Les listes de contrôle liées au travail ne peuvent être clôturées que lorsque tous les points sont cochés.

Le technicien voit sur son téléphone les travaux qui lui sont affectés et reçoit une notification lorsqu'un nouveau travail arrive. Il prend le travail en charge, ajoute le matériel prélevé à l'entrepôt, met le statut à jour depuis le terrain ; lorsqu'il met le travail en attente, il en indique la raison, et lorsqu'il le termine, il saisit sa note. Chaque étape est enregistrée avec son horodatage et le panneau d'administration est actualisé en même temps. Les coûts de matériel, de main-d'œuvre et de fournisseur s'accumulent eux aussi dans le même ordre de travail ; les coûts estimé et réalisé, ainsi que les services internes et externes, sont tenus séparément. L'enregistrement de la panne peut être associé à un actif, à un local technique ou à un emplacement, le niveau de criticité détermine la priorité, et le début et la clôture de l'intervention sont conservés avec leur horodatage. Le gestionnaire peut lui aussi donner l'approbation et l'acheminement de l'ordre de travail, ainsi que les approbations des utilisateurs et des visiteurs, depuis l'application mobile du gestionnaire.

Les sous-sols et les locaux techniques sont les endroits où la connexion est la plus faible. Nous avons donc conçu les flux terrain en prévoyant le fonctionnement hors ligne, et fixé dès le départ par des règles le comportement des applications mobiles en cas de perte de connexion : le brouillon du formulaire n'est pas perdu, l'utilisateur voit clairement qu'il est hors ligne, le renvoi se fait sans créer d'enregistrement en double. La règle la plus importante est la suivante : une opération non enregistrée n'est jamais présentée à l'utilisateur comme réussie.

Lorsque le travail est clos, le cycle se termine chez le résident. L'auteur de la demande note le service sur cinq étoiles et laisse un commentaire ; une seconde évaluation principale n'est pas possible pour la même demande. Le SLA devient ainsi la mesure non seulement du délai, mais aussi de la satisfaction.

Ce que nous avons appris sur le terrain

• Ne laissez pas la localisation en texte libre. Quand le bâtiment, l'appartement et l'espace sont choisis dans le système, les règles d'acheminement fonctionnent elles aussi correctement.
• Gardez la règle simple. Des règles fondées sur la localisation et l'ordre restent assez claires pour que le gestionnaire les comprenne et les maintienne.
• Un travail non affecté est aussi un statut. La demande que la règle ne trouve pas ne se perd pas : elle arrive devant le gestionnaire.
• Une interface honnête sur le terrain. Une application qui ne dit pas « enregistré » quand il n'y a pas de connexion permet au technicien comme à la gestion de faire confiance au système.

Le délai de clôture d'une demande s'allonge surtout dans les minutes où personne ne s'en saisit. Lorsque vous liez la prise en charge à une règle, le délai devient lui aussi visible.

Combien de temps dure le parcours d'une panne dans vos résidences ?

Si vous venez d'une organisation où les demandes se perdent dans des groupes de messagerie, où le travail de l'équipe terrain n'est pas enregistré ou où le SLA ne peut pas être mesuré, nous pouvons concevoir avec vous un flux qui fonctionne avec vos propres règles. Vous pouvez consulter la page du projet Logiciel de gestion de copropriété ou nous contacter.