StetBoard

Le point de départ

STET installe et entretient des équipements thermiques et de climatisation en Île-de-France. Une entreprise de terrain : des équipes qui partent le matin sur des chantiers différents, des achats de matériel décidés sur place, et un bureau qui doit reconstituer le soir ce qui s'est passé dans la journée.

C'est cette reconstitution qui coûtait cher, et pas seulement en temps. Un bon de livraison griffonné dans une camionnette, un ticket de fournisseur qui reste dans une poche, un chantier dont personne ne sait exactement ce qu'il a consommé : chaque information existait, quelque part, mais elle n'arrivait au bureau qu'au prix d'un aller-retour et d'une ressaisie.

Le sujet initial était donc les achats — savoir ce qui avait été commandé, à qui, pour quel chantier, et à quel stade de paiement. Le reste est venu ensuite, chaque fois pour la même raison : une information existait sur papier ou dans une boîte mail, et personne ne la retrouvait au moment où elle servait.

La particularité de cette entreprise, et ce qui a le plus pesé sur la conception : l'outil devait servir à tout le monde. Le dirigeant qui pilote, l'administratif qui saisit, le chef d'équipe qui rend compte, et l'ouvrier qui achète une pièce chez un fournisseur. Quatre métiers, quatre rapports à l'écran, et un seul logiciel.

Ce qui a été construit

Une application de gestion interne, construite autour des achats puis élargie à ce qui gravite autour.

• Achats : commandes rattachées au chantier, catégories, fournisseurs et leurs contacts, règlements, suivi des opérations.
• Terrain : chaque salarié a son QR code personnel. Il le scanne chez le fournisseur et déclare l'achat depuis son téléphone, sans compte ni application à installer.
• Personnel : contrats de travail, présences, demandes de congés — déposées elles aussi par un simple lien, sans identifiants — et jours fériés générés d'avance.
• Documents : dossiers, versions successives, pièces jointes, commentaires.
• Archivage : sortie automatique des données closes, sauvegarde nocturne.

Le déroulé

Une question a décidé de presque tout : comment fait-on entrer dans un logiciel de gestion des gens qui ne sont pas devant un écran ? Le bureau, lui, sait se servir d'un formulaire. L'ouvrier au comptoir d'un fournisseur, non — et c'est pourtant lui qui détient l'information au moment où elle est juste.

Supprimer le compte plutôt que former les gens

Faire saisir un achat à un ouvrier suppose d'ordinaire un compte, un mot de passe, une application, et une demi-journée de formation pour une action qui dure trente secondes. À ce prix-là, personne ne s'en sert : l'information repart dans la poche et le bureau ressaisit.

Chaque salarié a donc son QR code personnel, imprimé une fois. Il le scanne avec l'appareil photo de son téléphone — iOS et Android le font nativement — et une page s'ouvre, qui le reconnaît déjà. Il cherche le fournisseur, ou le crée s'il est nouveau, et l'achat part au bureau. Aucune application, aucun identifiant, rien à retenir.

Le même principe sert les demandes de congés : un lien personnel, un formulaire, pas de compte. Deux usages qui n'ont rien à voir, un seul raisonnement — quand l'utilisateur n'est pas un utilisateur quotidien, le compte est l'obstacle, pas la sécurité.

Le compromis est assumé et il est proportionné : ces jetons donnent accès à un formulaire de déclaration, pas au logiciel. Un lien qui circule permet de déclarer un achat, ce qu'un contrôle au bureau rattrape ; il ne donne à voir ni les prix, ni les clients, ni la paie.

Rattacher chaque dépense à son chantier

Un achat ne se résume pas à un montant : il est engagé pour une opération. Le lien est posé dès la déclaration, sur le terrain, et non reconstitué au bureau à partir d'une date et d'un souvenir.

C'est ce qui change la nature de l'information. Sans ce rattachement, on sait ce qu'on a dépensé dans le mois ; avec, on sait ce qu'a coûté un chantier. La première donnée sert à payer les factures, la seconde à décider si on refait ce type de chantier au même prix.

Générer les jours fériés une fois par an, d'avance

Un détail qui dit beaucoup du reste. Les jours fériés sont calculés et enregistrés par une tâche planifiée annuelle plutôt que recalculés à chaque affichage.

La raison est métier, pas technique : un jour chômé propre à l'entreprise peut être ajouté ou retiré à la main, et un calcul à la volée écraserait la correction à chaque page. Les données de référence qui admettent une exception humaine doivent être stockées, pas recalculées.

Archiver plutôt que purger

Une tâche nocturne sort les données closes du champ courant, et une autre sauvegarde la base. Rien n'est supprimé : archivé signifie hors de vue, pas perdu.

Sur une application de gestion, la distinction est essentielle. Les écrans respirent — les listes ne portent plus quatre ans d'historique — et les obligations de conservation restent tenues. Une purge aurait donné le premier bénéfice en détruisant le second.

Produire les documents que les tiers exigent

Tableur, traitement de texte, PDF, QR code, cartographie. Ces briques ne sont pas un catalogue de gadgets : chacune correspond à un document qu'un comptable, un fournisseur ou une administration réclame dans son format, et qu'il faudrait sinon refaire à la main après chaque export.

La règle appliquée : l'application produit le document final, pas une donnée brute à remettre en forme. C'est là que se gagne le temps réel des utilisateurs — celui qu'on ne voit pas dans un cahier des charges et qui se compte en heures par mois.

Ce que ça a changé

Deux changements, du point de vue de l'entreprise.

La ressaisie a disparu. Ce qui était noté à la main sur le terrain puis retapé au bureau arrive directement dans l'outil, saisi une fois, par la personne qui était là. C'est le gain qui se mesure en temps administratif, et c'est celui qu'on avait visé.

Plus rien ne se perd. Justificatifs, contrats, documents, historiques de chantier : tout est versé au même endroit et se retrouve. C'est le gain qu'on n'avait pas visé, et c'est celui dont on parle le plus — parce qu'il ne se voit qu'au moment où l'on cherche une pièce, et qu'à ce moment-là il vaut tout le reste.

L'application tourne en production et sert quotidiennement. Deux cent soixante-neuf commits sur trois ans, à un rythme de petites évolutions plutôt que de grandes versions — ce qui correspond à la manière dont l'entreprise formule ses besoins : rarement en projet, souvent en agacement précis.