PotoP Enterprise Suite

Le planning est une vue sur les mêmes enregistrements d’interventions et d’absences que ceux du tableau de planification, regroupés par jour, avec le total des heures planifiées à côté des heures pointées par la personne. Rien de plus n’est stocké pour cela. Le lien d’agenda est une adresse privée et révocable qui fournit un flux iCalendar standard : Outlook, Google Agenda ou l’agenda d’un téléphone peuvent s’y abonner et l’actualiser eux-mêmes. L’adresse contient un jeton secret et peut être désactivée à tout moment, ce qui coupe immédiatement le flux.

Un projet est l’enregistrement qui regroupe les interventions, avec un client et un budget. La page additionne les heures réalisées issues des feuilles de temps approuvées et les heures planifiées du tableau de planification, toutes lues dans PostgreSQL à l’ouverture de la page : les totaux correspondent donc toujours aux saisies sous-jacentes. Les dossiers d’ingénierie, les travaux supplémentaires et les matériaux sont rattachés au projet par de simples relations de base de données, et chaque onglet est une vue distincte générée par le serveur, qui n’apparaît que si l’entreprise dispose d’une licence pour ce module et si l’utilisateur a l’autorisation de la consulter.

La liste est la vue personnelle du technicien sur la table partagée des interventions : celles qui lui sont attribuées, regroupées par jour, avec les statuts qu’elles traversent au fil du travail. Le partage de position est un interrupteur que le technicien contrôle, et le bandeau indique que le navigateur envoie une position à intervalle fixe tant que l’interrupteur est activé. Signaler une panne ouvre le même formulaire que celui du bureau : le signalement arrive directement dans la file des pannes. La page est adaptative et c’est la même que celle affichée par l’application Android.

Chaque panne est associée à une politique de niveau de service correspondant à sa priorité ; les échéances de première réponse et de résolution en sont déduites sur le serveur et enregistrées avec la panne. Les plans et les entrées du Whitebook sont liés via l’installation à laquelle appartient la panne. La messagerie de la panne est la même messagerie chiffrée de bout en bout que partout ailleurs : le chiffrement et le déchiffrement se font dans le navigateur, et le serveur ne détient que des données chiffrées. Chaque visite, changement de statut et mise à jour est consigné dans l’historique de la panne avec le nom de la personne et l’heure.

Un bon de travail est une fiche d’intervention reliée à tout ce qui l’entoure. Le plan et les documents sont des liens vers l’installation et ses fichiers stockés, les instructions sont le texte rédigé par le bureau pour le chantier, et l’historique est une piste d’audit indiquant qui a modifié quoi et quand. Les techniciens saisissent leur temps sous forme de segments, marqués soit comme pointés avec un bouton, soit comme saisis après coup : une correction reste ainsi visible au lieu de réécrire en silence ce que le téléphone a enregistré. Le matériel imputé ici est déduit du stock et apparaît sur le projet.

Une fiche est classée sous un type de système, avec le même vocabulaire que les plans techniques : elle apparaît donc pour chaque installation de ce système. Les photos sont prises avec l’appareil photo du téléphone ou du navigateur, et de simples croquis sont dessinés du doigt sur un canevas puis enregistrés comme images à côté du texte. Lire, modifier et ajouter une note sont des droits distincts. Les fiches peuvent être imprimées en PDF, et le lien vers les personnes qui connaissent le système provient des évaluations de compétences tenues dans le module Personnel.

Chaque carte est une description de système stockée sous forme de données : ses types de composants, les connexions autorisées entre eux et les tableaux de numéros et d’adresses dont le document technique a besoin. L’éditeur étant générique, prendre en charge un autre fabricant revient à ajouter une nouvelle description, pas du nouveau code. Les compteurs des cartes sont tirés de ces descriptions au chargement de la page. L’entrée PotoP VMS Studio est l’une de ces descriptions : c’est elle qui permet de transformer un plan en une configuration de caméras et d’enregistrement opérationnelle sur un serveur VMS.

Tout composant de n’importe quel plan peut porter une date de fin de certificat, et cette page les rassemble toutes pour l’entreprise en une seule requête, triées par jours restants. Une tâche de fond vérifie les dates chaque jour et envoie des avertissements à six, trois, deux et un mois, puis à vingt, dix et un jour avant l’échéance, et une fois après l’expiration. Les avertissements partent par e-mail, par Telegram et dans la suite, vers les personnes autorisées à modifier les plans. Chaque étape d’avertissement est enregistrée sur l’élément lui-même : un redémarrage ou une seconde exécution ne la répète jamais.

Un cycle est calculé sur le serveur à partir des données déjà présentes dans le produit : le contrat, le salaire avec sa date d’effet, les heures approuvées par un responsable et ventilées selon les codes et coefficients horaires propres à l’entreprise, les pourcentages de congé et de maladie, ainsi que les notes de frais approuvées. Le brut, l’impôt et le net en découlent, et le contrôle préalable liste les personnes sans fiche de salaire avant tout calcul. Les fiches de paie sont produites en PDF, et le lot de paiements peut être exporté en fichier SEPA ou transmis à l’API de paiement d’une banque, où une personne l’autorise toujours auprès de la banque.

Les heures sont saisies sur un projet ou un bon de travail et enregistrées comme segments de temps dans la base de données. La page les compare aux interventions et au planning de la même semaine, et signale ainsi le travail prévu mais non imputé. Soumettre la semaine la verrouille pour validation par un responsable, et seules les semaines approuvées alimentent la paie et les totaux d’heures des projets. Les segments indiquent s’ils ont été pointés avec un bouton ou saisis après coup, ce qui garde les corrections visibles et attribuables à une personne nommée.

Une facture fournisseur est saisie avec son PDF scanné en pièce jointe, puis passe par les statuts vérifiée, approuvée et payée, chaque étape étant enregistrée avec la personne qui l’a effectuée. L’approbation crée l’écriture comptable : la dette apparaît immédiatement dans les livres. Les factures approuvées peuvent être réunies en un seul lot de paiement et exportées en fichier de virement SEPA pour la banque en ligne, ou envoyées à l’interface d’initiation de paiement d’une banque, où une personne autorise le paiement. Les compteurs d’échéances et de retards sont calculés à partir des conditions de paiement.

La comptabilité est un grand livre en partie double dans PostgreSQL. Chaque chiffre de cette page est une somme de lignes comptabilisées, calculée à l’affichage de la page : un total enregistré ne peut donc jamais contredire les écritures sous-jacentes. D’autres modules comptabilisent automatiquement, par exemple la paie, l’amortissement des immobilisations ou une facture d’achat approuvée, et chaque écriture garde une référence à sa source. Les contrôles au-dessus de la liste vérifient le grand livre lui-même, par exemple l’égalité entre débit et crédit. Corriger une pièce source la recomptabilise au lieu de laisser une écriture orpheline.

Les rapports n’écrivent jamais rien. Le bilan, le compte de résultat, la balance et les journaux sont des requêtes sur les lignes comptabilisées de la période choisie : ils sont toujours à jour et chaque chiffre peut être rattaché à ses écritures. Les résultats peuvent être téléchargés en CSV, et les exports tableur suivent la mise en page maison de la suite. Les comptes annuels sont produits en PDF, et le fichier d’audit est un fichier XML standard lisible par un expert-comptable ou par les outils de l’administration fiscale. La consultation des rapports nécessite une autorisation propre.

Un outil est un enregistrement doté de son propre intervalle d’inspection, de son échéance d’assurance et de son tarif journalier. Inspections et réparations sont consignées sous forme d’entrées avec leur coût, et la date de la prochaine inspection est calculée à partir de la dernière enregistrée. Les réservations sont des lignes qui relient l’outil à un ordre de travail et à des dates : deux chantiers ne peuvent pas réserver la même échelle sans que personne ne s’en aperçoive. La tâche quotidienne en arrière-plan qui surveille les échéances peut avertir par e-mail et dans la suite, et le tarif journalier alimente les coûts des projets.

Le coffre-fort est à divulgation nulle de connaissance. Chaque utilisateur dispose d’une clé dérivée d’une phrase secrète avec PBKDF2 et d’une paire de clés P-256, et chaque élément possède sa propre clé aléatoire, son contenu étant scellé en AES-GCM dans le navigateur avant l’envoi. Le serveur stocke des données chiffrées et des clés enveloppées ; il peut lister, compter et partager, mais ne peut rien ouvrir. Le bilan de santé s’exécute donc dans le navigateur après déchiffrement, en comptant localement les mots de passe faibles, réutilisés et anciens. Le partage enveloppe la clé d’un élément pour une collection, et l’entreprise peut détenir une clé de récupération.

L’assistant est un ensemble d’actions, pas un modèle livré à lui-même. Les questions — où se trouve un appareil, ce qui est planifié aujourd’hui, qui connaît un système — reçoivent leur réponse via des requêtes en base de données qui respectent les autorisations de la personne qui demande. Les actions qui modifient des données sont signalées et demandent une confirmation. Un modèle de langage est facultatif : l’entreprise peut connecter n’importe quel point d’accès compatible OpenAI, y compris un modèle local comme Ollama sur son propre matériel, et tout fonctionne sans lui. Les réponses sont générées en arrière-plan, de sorte que les longues générations n’expirent pas.

Les graphiques sont agrégés sur le serveur à partir des mêmes tables opérationnelles que celles utilisées par le reste de la suite : interventions terminées, pannes, heures pointées et activité de connexion par jour. Les avertissements proviennent de contrôles de santé, comme les échecs d’envoi d’e-mails ou les niveaux de service non respectés. Pour la supervision de l’infrastructure, PES expose aussi un point de terminaison de métriques au format texte Prometheus, que Grafana, Zabbix ou Uptime Kuma peuvent collecter. Les opérateurs peuvent en outre être alertés par e-mail et Telegram en cas de nouvelle erreur ou d’événement de sécurité.

Chaque rapport est une requête en lecture seule sur les pannes et leurs échéances enregistrées, regroupées par priorité, par client et par équipe. Les pourcentages s’affichent avec les chiffres qui les sous-tendent, par exemple 47 sur 50, pour qu’un résultat puisse être justifié. La période et les filtres utilisés figurent sur le rapport. Les PDF sont générés sur le serveur, les fichiers Excel et CSV sont produits comme fichiers, et l’envoi hebdomadaire s’exécute comme tâche de fond qui envoie le rapport final aux destinataires choisis, avec les paramètres de messagerie de l’entreprise.

Les mots de passe sont stockés sous forme de hachages Argon2id et les sessions sont conservées sur le serveur, ce qui permet à un administrateur d’en révoquer une. La vérification en deux étapes utilise des codes temporels standard avec codes de récupération, les passkeys reposent sur WebAuthn, et une entreprise peut imposer la vérification en deux étapes à tous. Les utilisateurs appartiennent à des groupes porteurs d’autorisations. Les comptes peuvent être créés en masse à partir d’un tableur, avec un mot de passe généré envoyé par e-mail, ou synchronisés depuis Active Directory ou LDAP ; les personnes qui partent y sont désactivées plutôt que supprimées. Chaque modification est inscrite dans la piste d’audit.