Les bots travaillent, vous regardez.

Ce que ça fait

Quatre bots sont livrés avec le produit, et le SDK sert à en écrire d'autres.

Surtout : quand ça casse

C'est là qu'un outil d'automatisation se juge. Un bot qui marche ne demande rien à personne.

• La capture au moment de l'échec. Ce que le navigateur avait à l'écran quand le bot s'est arrêté — pas une page rechargée dix minutes plus tard, quand le problème a disparu.
• La trace Playwright, à rouvrir dans l'outil officiel : chaque action, chaque attente, l'arbre du DOM à chaque étape.
• Les paramètres exacts avec lesquels il est parti, et le journal complet.

Deux cents messages, trois pannes

L'écran de pilotage répond à une question : qu'est-ce qui casse le plus souvent, et depuis quand.

• Les messages sont regroupés par cause. Les adresses, les nombres et les identifiants sont remplacés par des marqueurs : deux cents lignes uniques redeviennent les quelques pannes qu'elles sont.
• Chaque groupe garde un exemple réel sous sa signature, et la période pendant laquelle il a été vu. Une cause qui date d'un mois ne se traite pas comme une qui est apparue ce matin.
• Taux de réussite, durée médiane, 95ᵉ centile — et la période s'exporte en CSV.

À l'échelle d'une organisation

Le même modèle d'entités et de droits que Tick&, et pour la même raison.

• Le cloisonnement est appliqué par PostgreSQL, en Row-Level Security — pas par des clauses WHERE qu'on peut oublier d'écrire. Des tests d'intégration le vérifient contre une vraie base, et ils échouent tous quand on les pointe sur le rôle propriétaire.
• Un droit est un triplet objet × action × portée, et l'absence de ligne vaut refus.
• Chaque bot est mis à disposition par entité et par profil. L'entité dit où il a le droit de tourner, le profil dit qui, là-bas, peut le lancer.
• Comptes LDAP et Active Directory, avec des règles d'affectation groupe → profil + entité. La base locale est interrogée d'abord : un compte d'administration de secours n'est jamais bloqué par un annuaire injoignable.

Cinq comptes, cinq portées

La démonstration est amorcée avec cinq comptes, mot de passe commun flow. Chacun illustre un cas que le modèle doit savoir traiter — et sur Flow&, le cloisonnement porte sur deux choses à la fois : ce qu'un compte voit de l'organisation, et quels bots lui sont ouverts.

• sophie — Supervision sur Pôle Industrie, récursif. Voit la branche entière et sa descendance, ses exécutions et ses statistiques, sans rien apercevoir du Siège. Trois bots lui sont ouverts. Le compte à essayer en premier : celui qui montre le plus sans être administrateur.
• admin — Administration sur Groupe Vercors, récursif. L'arborescence complète et les écrans de configuration : entités, profils, droits, règles de mise à disposition des bots, clés d'API et plugins. Le seul à voir « Espace connecté », et seulement en se plaçant sur le Siège — la règle qui l'ouvre nomme une entité et un profil.
• thomas — Opérateur sur Site de Lyon, non récursif. Une seule entité, sans sa descendance, et rien d'autre que les exécutions de cette entité-là. La différence avec sophie montre ce que la récursivité change.
• lea — Opérateur sur Site de Saint-Étienne et Observation sur Siège. Le cumul d'habilitations : les droits suivent le profil actif, jamais l'union des deux. Changer de contexte en haut de l'écran change ce qu'elle voit — et les bots disponibles changent avec.
• marc — Observation sur Groupe Vercors, récursif. Voit tout et ne lance rien : le profil n'a pas le droit d'exécuter. Le compte du responsable qui suit les chiffres sans toucher à la production.

Aucune inscription, aucune donnée collectée. Tout est remis à zéro à chaque heure — lancez, cassez, supprimez. Les quatre bots livrés n'ont aucun paramètre libre : on ne fait pas visiter au serveur ce qu'on veut. La démonstration de Tick& est à côté.

Aucun bot livré ne prend d'adresse

Ce n'est pas un oubli, et c'est le détail le plus important de tout l'outillage d'exemple.

• Un bot qui ouvre l'adresse qu'on lui donne fait du serveur qui l'héberge un relais ouvert — vers son réseau interne comme vers n'importe quel site tiers, depuis son adresse IP et sous son nom de domaine. C'est la première chose qui casse sur une instance ouverte à tous.
• Les quatre bots livrés n'ont que des paramètres fermés : listes d'énumération, booléens, entiers bornés. Trois visitent des bacs à sable publiés pour l'exercice — jamais un site qui n'a rien demandé. Le quatrième ne sort pas de la machine du tout : il sert sa propre page.
• La contrainte est posée dans les bots, pas dans la configuration de la démonstration. Un refus posé ailleurs n'aurait protégé qu'elle, et laissé le piège ouvert pour qui écrit son premier bot en copiant les nôtres.

Chez vous, sur vos serveurs

En conteneurs ou sans, sous Linux comme sous Windows Server. Rien ne sort de votre machine.

• Le guide d'installation détaille les secrets à générer, la rotation obligatoire du mot de passe du rôle applicatif, les sauvegardes et les montées de version — docs/23-installation.md .

Où en est le projet, dit franchement

La 0.3.2 est publiée. Voici ce qu'il faut savoir avant de s'en servir.

• Jamais utilisé en production par personne. Le chemin d'installation en conteneurs a été déroulé sur une machine vierge, et les quatre défauts rencontrés corrigés dans le code — mais aucune organisation n'a encore fait tourner de vrais bots avec Flow&.
• Les chemins d'installation sans conteneur n'ont pas été déroulés, ni sous Linux ni sous Windows Server. Un blocage y est attendu, et le signaler est la contribution la plus utile au projet aujourd'hui.
• Le majeur est à zéro : une version mineure peut rompre, et le journal le dit. Les deux SDK — bots et plugins — sont dans le même cas.
• Un plugin s'exécute dans le processus de l'API, avec ses privilèges. Il n'y a pas de bac à sable : l'installer engage autant que déployer une version.