Quatre façons de nous faire travailler.

Une application complète quand l'outil n'existe pas. Un agent quand il fait gagner du temps sur un geste précis. Une formation quand vos équipes doivent tenir la barre elles mêmes. Chaque exemple ci dessous tourne déjà.

Cas d'usage 01

Full App, quand l'outil n'existe pas

Vous pilotez votre activité dans un tableur, ou dans un logiciel qui parle un métier différent du vôtre. On construit la plateforme qui manque, et on la fait vivre en production.

Du modèle de données aux écrans Trois entités métier forment le modèle de données. Il produit les écrans de travail, puis les comptes et les rôles qui disent qui voit quoi. le modèle client dossier pièce dossiers rôles admin
01

Le modèle de données

On part de votre métier, pas d'un gabarit. Quelles entités existent vraiment, ce qui les relie, ce qui doit être unique, ce qui peut manquer. C'est la décision la plus coûteuse à corriger plus tard, donc la première qu'on prend au contact des utilisateurs.

Sur vos données réelles, pas sur un jeu d'essai
02

Les écrans métier

Un écran par geste réel, dans l'ordre où le travail se fait. Le périmètre se réduit avant de s'étendre : on retire ce qui oblige à choisir plutôt que d'ajouter une fonction de plus.

Livrés par lots, mis entre les mains des utilisateurs
03

Les comptes et les rôles

Qui voit quoi, qui peut quoi. Authentification, organisations séparées, droits par rôle, journal des actions sensibles. C'est ce qui permet à l'outil de sortir d'une équipe et de servir toute la maison.

Cloisonnement vérifié avant la mise en ligne
04

La mise en production

Hébergement identifié, sauvegardes, restauration testée, reprise de l'existant sans rupture d'adresses. Puis on fait vivre : correctifs, évolutions, et un interlocuteur qui connaît votre système.

France ou Union européenne, écrit au contrat

La méthode détaillée : livrables, résultats, enjeux

Cas d'usage 02

Agent IA, quand un geste précis prend trop de temps

Un agent utile ne remplace pas votre métier, il absorbe la question qu'on vous pose quarante fois par jour. Chez nous, le modèle ne rédige que de la prose : un prix, une disponibilité ou une adresse sont calculés par le serveur, puis relus avant affichage.

Le trajet d'une question Une question entre. L'agent répond depuis un corpus fermé en citant sa source. Ce qui engage l'entreprise est calculé par le serveur, et l'agent passe la main dès qu'un conseil est en jeu. la question assistant source citée calculé par le serveur je passe la main
01

Le périmètre, écrit avant le code

On écrit ce que l'agent doit faire et surtout ce qu'il ne doit jamais faire. La liste des sujets interdits est plus courte qu'on ne croit, et plus importante que le reste.

Un document relu et signé avant le premier appel au modèle
02

Des réponses tirées de vos contenus

L'agent répond depuis un corpus fermé : vos pages, votre catalogue, vos informations pratiques. Il cite d'où vient la réponse. Quand l'information n'existe pas, il le dit et renvoie vers vous, au lieu d'inventer.

Corpus fermé, source citée, droit de ne pas savoir
03

Le calcul côté serveur

Un prix, une disponibilité, une adresse n'est jamais produit par le modèle : le serveur le calcule à partir des données réelles et l'insère dans la réponse. Un montant qui apparaît là où il ne devrait pas déclenche le remplacement de la réponse entière.

Le modèle rédige, il ne chiffre pas
04

La reprise par un humain

L'agent se présente comme un agent et sait passer la main. Sur tout ce qui relève du conseil ou de la vente, il oriente vers la personne compétente. Le back office vous montre chaque question restée sans réponse.

Transparence, et une sortie vers vos équipes

La méthode détaillée : livrables, résultats, enjeux

Cas d'usage 03

Automatisation, quand un flux se répète sans personne pour le tenir

Tout n'a pas besoin d'une conversation. Beaucoup de gestes coûteux sont des enchaînements silencieux : produire un document, relancer au bon moment, collecter une donnée, publier. Ils tournent sans interface, et personne ne les voit tant qu'ils fonctionnent.

La chaîne d'un traitement, et son journal Un déclencheur lance le traitement, qui produit des sorties. Chaque passage laisse une ligne dans le journal, et un échec déclenche une alerte au lieu d'être découvert plus tard. journal des passages déclencheur traitement sorties 08:00 09:00 10:00 échec, alerte envoyée 11:00
01

Le déclencheur

Ce qui met le traitement en route : un formulaire reçu, un fichier déposé, une heure de la journée, un événement dans un autre outil. On l'écrit noir sur blanc, parce que c'est là que se logent les surprises.

Un seul point d'entrée, identifié
02

Le traitement

Il tourne sans qu'on le lance. Un brief qui devient un site publié, une relance partie au bon moment, des données collectées au fil de l'eau. Pas d'appel à un modèle pour ce qu'un script fait mieux et moins cher.

Le plus simple qui fait le travail
03

Les sorties

Emails, documents, mises à jour dans vos outils. Chaque envoi part d'un modèle que vous relisez, avec une adresse d'expédition authentifiée pour ne pas finir en indésirable.

Rien ne part sans que vous ayez vu le gabarit
04

Le journal et les alertes

Une automatisation muette est une automatisation dangereuse. Chaque passage laisse une trace lisible, et l'échec vous est signalé au lieu d'être découvert trois mois plus tard.

On voit ce qui s'est passé, et ce qui a raté

La méthode détaillée : livrables, résultats, enjeux

Cas d'usage 04

Formation, quand vos équipes doivent tenir la barre

Nous formons à ce que nous pratiquons tous les jours, dans nos propres projets. Pas de panorama des outils du moment : la manière de cadrer un usage, d'écrire des consignes qui tiennent, et de savoir ce qu'on ne doit jamais confier à un modèle.

01

Cadrer un usage, avant d'ouvrir un outil

Séparer ce qui peut être automatisé de ce qui ne doit pas l'être. Repérer les gestes répétitifs qui coûtent vraiment, et écarter ceux dont l'automatisation créerait un risque plus grand que le gain.

Format atelier, une demi journée
02

Écrire des consignes qui tiennent

Une consigne se juge sur ce qu'elle empêche, pas sur ce qu'elle demande. Listes fermées, interdictions explicites, vérification par le serveur : on rejoue les cas où un modèle a inventé un prix ou une garantie, et on construit le filtre qui l'arrête.

Format atelier, une journée
03

Travailler avec des agents au quotidien

Notre propre méthode de production, transmise telle quelle : découper le travail par métier, router chaque demande vers la bonne compétence, écrire les garde fous après chaque incident, et garder une mémoire qui survit aux sessions.

Format accompagnement, sur plusieurs semaines
04

IA responsable et sobriété numérique

Ce que le RGESN et l'AFNOR Spec 2314 changent concrètement dans une décision de conception. Mesurer avant d'optimiser, et savoir dire qu'un projet ne mérite pas d'être développé.

Format atelier, une demi journée

À noter : ces formats décrivent ce que nous savons transmettre, tirés de nos projets en production. Ce ne sont pas des sessions déjà cataloguées ni des références clients. Le contenu se construit avec vous, à partir de vos propres cas.

La méthode détaillée : livrables, résultats, enjeux

Notre façon de travailler

Le framework qu'on utilise pour construire tout ça

Nos projets ne sont pas tenus par une personne qui sait tout. Ils sont tenus par une méthode écrite, qu'on applique à nos produits comme à ceux de nos clients, et qu'on peut transmettre.

Le trajet d'une demande dans le framework Une demande est routée vers l'un des treize métiers outillés, passe la recette, puis part en livraison. Les garde fous entourent tout le trajet, et ce qui a été appris revient en mémoire pour la session suivante. Garde fous, actifs sur tous les projets 13 métiers outillés Demande Routage Recette Livraison Design Intégration Back office Sécurité Déploiement + 8 autres métiers Mémoire, rechargée à la session suivante Le trajet d'une demande dans le framework Une demande est routée vers l'un des treize métiers outillés, passe la recette, puis part en livraison. Les garde fous entourent tout le trajet, et ce qui a été appris revient en mémoire pour la session suivante. Garde fous, actifs sur tous les projets 13 métiers outillés Demande Routage Recette Livraison Design Intégration Back office Sécurité Déploiement + 8 autres métiers Mémoire, rechargée à la session suivante
13 Métiers outillés
22 Procédures écrites
100+ Clients déployés
0 Prix inventé
01

Un métier, une compétence

Design, intégration, back office, sécurité, référencement, déploiement, recette : chaque domaine a son responsable et sa procédure écrite, au lieu d'un généraliste qui improvise partout.

02

Un routage, pas une improvisation

Une demande entrante est reconnue à ses signaux et dirigée vers la bonne compétence. Quand deux domaines se contredisent, on arbitre avant d'exécuter, jamais après.

03

Des garde fous écrits après incident

Chaque règle transverse a coûté quelque chose une fois. Elles sont écrites, actives sur tous les projets, et certaines sont vérifiées automatiquement à chaque modification de fichier.

04

Une mémoire qui survit aux sessions

Ce qu'on apprend sur un projet est consigné et rechargé la fois suivante. Un piège rencontré une fois ne se paye pas deux fois.

05

Une porte de sortie avant livraison

Recette sur plusieurs largeurs d'écran, contrôle de sécurité, détection des tics d'écriture automatique. Ce qui n'est pas vérifié n'est pas annoncé comme fait.

Parlons en

Lequel de ces trois cas ressemble au vôtre ?

On commence toujours par un diagnostic : ce qui peut être automatisé, ce qui ne doit pas l'être, et ce que ça coûte vraiment.

Réserver un diagnostic Voir nos produits