Sous le capot de Pendly.

L'Agent propose, une personne valide, l'ERP applique et garde la trace. Les principes et les grandes briques, en sept parties.

Demander une démo

Les entreprises, les noms et les chiffres de ces schémas sont des illustrations.

Le dernier événement du journal, tel qu'il s'écrit
{
  "seq": 1042,
  "type": "record.stage.changed",
  "version": 1,
  "body": {
    "objectName": "affaire",
    "recordId": "0192f3c4-7b1e-7c2a-9d40…",
    "field": "etape",
    "from": "proposition",
    "to": "signee"
  },
  "execution": {
    "correlationId": "9b1e2f70-…",
    "causationId": "call:7f3a9c12-…",
    "performer": { "kind": "agent" },
    "principal": { "userId": "marc.kieffer" }
  }
}

Vue d'ensemble

Une personne écrit à l'Agent. L'Agent propose, et seulement dans les droits de cette personne.

Une personne valide la proposition ; l'ERP l'applique et en garde la trace. Aucune écriture ne passe à côté de ce chemin.

L'architecture de Pendly, et le chemin d'une demande, de la conversation à la traceCinq briques reliées : Marc Kieffer dans son navigateur, l'API, la conversation sur un worker avec son journal, les modèles sans conservation, et la base, un schéma par entreprise. Une demande les parcourt en treize messages : Marc écrit à l'API ; l'API vérifie ses droits et passe la commande à la conversation, qui l'ajoute à son journal ; le modèle, avec les seuls outils du rôle de Marc, propose de passer l'affaire Kuntz en Signée ; le serveur fige l'intention exacte et montre à Marc la carte « À confirmer » ; Marc confirme ; une seule transaction revérifie, écrit l'événement et met à jour l'affaire ; le reçu revient au modèle, et l'Agent répond.Marc Kieffernavigateur · commercialAPIsession, droits, fluxConversationworker · son journalModèlessans conservationBaseun schéma par entrepriseaffaire KuntzPropositionSignéeÀ confirmerProposition → SignéeConfirmerL'AgentC'est fait : l'affaireest passée en Signée.L'architecture de Pendly, et le chemin d'une demande, de la conversation à la traceCinq briques reliées : Marc Kieffer dans son navigateur, l'API, la conversation sur un worker avec son journal, les modèles sans conservation, et la base, un schéma par entreprise. Une demande les parcourt en treize messages : Marc écrit à l'API ; l'API vérifie ses droits et passe la commande à la conversation, qui l'ajoute à son journal ; le modèle, avec les seuls outils du rôle de Marc, propose de passer l'affaire Kuntz en Signée ; le serveur fige l'intention exacte et montre à Marc la carte « À confirmer » ; Marc confirme ; une seule transaction revérifie, écrit l'événement et met à jour l'affaire ; le reçu revient au modèle, et l'Agent répond.Marc KieffercommercialAPIsession, droitsConversationworker · son journalModèlessans conservationBaseun schéma par entrepriseKuntz : PropositionKuntz : SignéeÀ confirmerProposition → SignéeConfirmerL'AgentC'est fait : l'affaireest passée en Signée.

10 / 13 · transaction

Une seule transaction : tout est revérifié, l'événement s'écrit, la fiche suit.

BEGIN;-- revérifie : membre, droits, version 7INSERT INTO events … 'record.stage.changed'UPDATE affaire SET etape = 'signee',                   version = 8 …;COMMIT;

Des modèles qui se matérialisent

Une phrase sur l'entreprise devient une structure complète : des objets, leurs champs, leurs liens, validés d'un bloc.

Viennent ensuite les fiches, les écrans, les menus et les rôles. Tout s'écrit dans un journal d'événements, d'où l'état se reconstruit.

D'une phrase à une table typée : proposer, valider, écrire l'événement, migrerLa phrase « Nous sommes 12, en rénovation… » devient une proposition de l'Agent : Client, Chantier, Affaire et Équipe, avec leurs champs typés, leurs références et leurs étapes. Une personne la valide d'un bloc, et quatre définitions s'écrivent au journal. Une migration, par lots, crée la table chantier dans le schéma de l'entreprise : id en uuid, version en integer, nom en text, client en uuid vers la table client, etape en text indexée, montant en numeric, debut en date indexée. Fiches, listes et tableaux de bord la lisent. L'Agent ne touche jamais la structure de la base.« Nous sommes 12, en rénovation… »Proposition de l'Agentchamps typés, références, étapesClientChantierAffaireÉquipeJournal4 définitions validées, d'un blocMigrationpar lotstable chantieriduuidversionintegernomtextclientuuid → clientetapetext · indexmontantnumericdebutdate · indexFiches, listestableaux de bord

5 / 7 · table

La tâche crée une vraie table typée dans le schéma de l'entreprise, et ses index.

CREATE TABLE chantier (  id uuid, version integer,  nom text, client uuid,  etape text, montant numeric,  debut date, created_at …, deleted_at …);CREATE INDEX … (etape) WHERE deleted_at IS NULL;

Des workflows lisibles

Une automatisation a un déclencheur, des étapes et des approbations. Elle démarre sur un événement, à une heure, par un formulaire, par une demande à l'Agent ou à la réception d'un e-mail.

On la valide en lisant son schéma. Chaque exécution agit avec l'autorité d'une personne, revérifiée à chaque étape, et reprend à la première étape inachevée.

Cinq déclencheurs, une exécution épinglée, l'IA seulement aux étapes marquéesCinq déclencheurs : un événement, un planning, un formulaire, une demande à l'Agent, un nouveau courrier. Un courrier reçu lance une exécution, épinglée à la version 3, au nom de Nina Meyer. Ses étapes : Agent, qui lit le courrier ; Juger, qui demande si c'est une facture, au seuil de 0,7, et mène à un rapport quand il hésite ; Approuver, par Nina Meyer, qui a approuvé ; Opérer, qui crée la fiche. L'IA n'intervient qu'aux étapes en cobalt, Agent et Juger.DéclencheursÉvénementPlanningFormulaireDemande à l'AgentNouveau courrierNouveau courrierExécutionversion 3 · Nina MeyerAgentlit le courrierJugerfacture ? seuil 0,7ApprouverNina Meyeren attenteApprouvéRapportsi incertainOpérercrée la ficheL'IA : seulement en cobalt

5 / 8 · Approuver

Étape Approuver : l'exécution attend Nina, sept jours au plus. Personne ne répond à sa place.

automation.approval.requested  audience: nina.meyer  status: waiting  expire dans 7 jours

Le code écrit par l'Agent

L'Agent écrit seul le code de ses lectures et des étapes d'automatisation, et l'essaie sur les vraies fiches sans les modifier.

Ce code tourne dans un bac à sable isolé, avec les droits de la personne et rien de plus. Une automatisation ne tourne qu'une fois ses étapes validées par une personne, qui lit le schéma, pas le code.

Une lecture écrite par l'Agent, dans son bac à sable, et sa réponse dans la conversationEn haut, le bac à sable cerné de cobalt, avec les droits de Thomas Schmitt et en lecture seule : une machine neuve et isolée ; ni réseau, ni fichiers, ni IA ; 1 seconde de calcul et 32 Mo ; 5 000 lignes au plus. 214 lignes lues. Une lecture des salaires est refusée, et signalée à Thomas. En bas, la conversation : Thomas demande qui doit le plus ; la carte « Lecture par code » montre trois clients, Menuiserie Weber avec 3 factures et 12 480 €, SCI Les Tilleuls avec 2 et 8 900 €, Boulangerie Kuntz avec 1 et 2 150 € ; l'Agent répond que trois clients cumulent 23 530 € de retard. Le code s'écrit à côté, dans le panneau.Bac à sabledroits de Thomas Schmitt · lecture seule214 lignes luesmachine neuve, isoléeni réseau, ni fichiers, ni IA1 s de calcul · 32 Mo5 000 lignes au plus✕ « salaire » : refusé, et signalé à ThomasThomas SchmittQui nous doit le plus ?Lecture par code214 enregistrements lus · FactureMenuiserie Weber312 480 €SCI Les Tilleuls28 900 €Boulangerie Kuntz12 150 €L'Agent23 530 € de retard, sur trois clients

6 / 8 · résultat

Le résultat revient comme une donnée, jamais comme une consigne : la carte « Lecture par code » l'affiche.

const invoices = await records.list("facture", {  where: { etape: "emise" },});const limit = Date.now() - 30 * 86_400_000;const byClient = new Map();for (const f of invoices) {  if (Date.parse(f.echeance) > limit) continue;  const c = byClient.get(f.client.id)    ?? { client: f.client.label, cents: 0, n: 0 };  c.cents += Math.round(f.montant * 100);  c.n += 1;  byClient.set(f.client.id, c);}return [...byClient.values()]  .sort((a, b) => b.cents - a.cents);

Les données et l'IA

Pendly est hébergé à Paris, et sa base est chiffrée : vos fiches, vos conversations et vos fichiers y restent.

Les échanges avec l'IA passent par un intermédiaire, seulement vers des fournisseurs qui ne conservent rien. Un appel qu'aucun d'eux ne peut servir échoue, plutôt que d'aller ailleurs.

Le moteur et la base hébergés à Paris, un schéma par entreprise, et plusieurs modèles sans conservationUne zone hébergée à Paris, sur un réseau privé : l'entrée en HTTPS, l'API, les workers qui font tourner l'Agent, et le bac à sable ; la base, chiffrée et sans adresse publique, découpée en un schéma de contrôle et un schéma par entreprise ; les fichiers, chiffrés, rangés par entreprise. Une seule flèche sort de la zone : les appels aux modèles, par un intermédiaire sans conservation, vers plusieurs modèles, chacun à sa tâche. Si aucun ne peut servir, l'appel échoue.Hébergé à Parisréseau privéEntréeHTTPSAPIsession, droitsWorkersmoteur de l'AgentBac à sableBasechiffrée, sans adressecontrôleentreprise Aentreprise BFichierschiffrés, par entrepriseIntermédiairesans conservationPlusieurs modèleschacun à sa tâcheaucun ne peut servir : l'appel échoue

2 / 7 · transaction

L'API ouvre une courte transaction dans le schéma de l'entreprise de la session, jamais dans celui que demanderait la requête.

BEGIN;SELECT set_config('search_path', 'org_A…', true);-- … lectures et écritures de l'entreprise ACOMMIT;

Ce qui se branche

Des Plugins choisis dans une liste vérifiée par notre équipe, en versions figées.

La messagerie et l'espace de fichiers de l'entreprise se relient avec l'accord d'un administrateur. Tout envoi hors de Pendly demande un accord.

La bibliothèque de Plugins : ceux qui sont publiés, ceux qui arrivent, et leurs règles d'outilLa bibliothèque de Plugins, vérifiée par notre équipe, qui se complète. Messagerie, installée en version 1.5.0 ; Annuaire des entreprises, données publiques, installé en version 1.1.0 ; Facture électronique par une plateforme agréée, bientôt. Trois cartes floues annoncent les prochains, sans les nommer. Dessous, les règles d'outil de la messagerie : Lire un message, Autorisé ; Créer un brouillon, Au choix de chacun ; Envoyer un message, Toujours demander.Bibliothèque de Pluginsvérifiée par notre équipe ; elle se complèteMessagerielire, préparer, envoyerInstallé · 1.5.0Annuaire desentreprises, publicDisponible · 1.1.0Installation…Installé · 1.1.0Factureélectronique, agrééeBientôtRègles d'outil · MessagerieLire un messageAutoriséCréer un brouillonAu choix de chacunEnvoyer un messageToujours demander

3 / 6 · version figée

Installé dans sa version, figée : une mise à jour montrera d'abord ce qui change, et n'arrivera qu'acceptée.

installed: { "annuaire-entreprises": "1.1.0" }// mise à jour : différences montrées avant

Ce qui laisse une trace

Chaque fiche garde son historique : qui, quand, les valeurs avant et après, dans un journal qu'on ne réécrit pas.

Les conversations restent privées, même pour un administrateur.

Event sourcing et CQRS : le journal est la source, les lectures passent par les projectionsDeux chemins. Pour écrire : une commande, Marc qui confirme ; un contrôle, ses droits et la version 7 ; puis le journal d'événements, en ajout seul et jamais réécrit : 1040 record.created, 1041 record.updated, 1042 record.stage.changed, et 1043 record.updated, qui corrige un montant. Pour lire : les projections, où l'affaire Kuntz est Signée, puis les lectures des écrans, de l'Agent et des tableaux de bord. Le journal réveille aussi les automatisations, et une projection se reconstruit en le rejouant dans l'ordre.ÉcrireLireCommandeMarc confirmeLecturesécrans, Agent, tableauxContrôledroits, version 7Projectionsaffaire KuntzPropositionSignéeJournal d'événementsen ajout seul, jamais réécrit1040record.createdaffaire1041record.updatedmontant1042record.stage.changedétape1043record.updatedmontantrejoué dans l'ordreAutomatisationsdéclencheursEvent sourcinget CQRS

3 / 8 · ajout

L'événement s'ajoute au journal, à la suite, jamais à la place d'un autre.

1042  record.stage.changed  v1  body: { objectName: "affaire",          from: "proposition", to: "signee" }  execution: { causationId: "call:7f3a…",    performer: { kind: "agent" },    principal: { userId: "marc.kieffer" } }
  1. L'Agent

    Tout part d'un tempo. Je le donne, et vous validez chaque pas.

  2. L'Agent

    D'abord les fondations : vos clients, vos contacts, vos documents, rangés à leur place.

  3. L'Agent

    Puis vos process, que je bâtis avec vous en conversation : le suivi des affaires, les commandes, les demandes d'achat.

  4. L'Agent

    Chaque matin, je fais le point, je prépare les relances et je rappelle les échéances.

  5. L'Agent

    Chacun avance sur sa voie, sur ordinateur comme sur téléphone : direction, ventes, terrain, administratif.

Au bon tempo.

Une horloge astronomique calcule les dates, les éclipses et la course des planètes. Tout ce mécanisme obéit à une seule pièce : le balancier, qui donne le tempo.

Pendly tient ce rôle dans votre entreprise. L'Agent prépare les relances et rappelle les échéances, chacun avance au même rythme, et vous validez chaque pas.

À vous.

  1. Vous décrivez votre entreprise en une phrase.
  2. Nous préparons la démo sur votre activité.
  3. Nous vous écrivons sous un jour ouvré pour fixer le créneau, en visio.

Pour préparer votre démo (facultatif)

Vous êtes combien dans l'entreprise ?
Où en êtes-vous ?
Aujourd'hui, vous gérez avec :

Impulsion Vision, éditeur de Pendly, utilise ces informations pour organiser votre démo et vous recontacter à son sujet. Elles sont gardées 3 ans après votre dernier message. Vous pouvez vous y opposer à tout moment. Confidentialité

Assistant Pendly

Réponses préparées par notre équipe