Nous intégrons l'IA dans les processus qui tournent déjà
Données, modèles, intégration avec vos systèmes et accompagnement après le lancement.
L'IA n'est pas ici un produit à part mais une couche de traitement posée sur les données que l'entreprise accumule déjà : commandes, demandes, documents, mouvements de marchandises, événements des équipements. Voici les directions de mise en place, chacune décrite par une même boucle : quelles données sont prises, ce que le modèle en fait, quelle décision ou quelle action en découle, et ce qui change dans le travail de l'entreprise.
Mettre en place l'IA — cela veut dire intégrer un modèle à un processus qui tourne déjà, et non lancer un système à part à côté. Le modèle lit les données de l'entreprise, y trouve un schéma et produit une décision ; l'action qui découle de cette décision est exécutée par le système dans lequel le processus vit — CRM, ERP, programme d'entrepôt, caisse, portail, messagerie.
C'est pourquoi un projet ne commence pas par le choix d'un modèle mais par quatre réponses : quelles données existent et dans quel état elles sont ; quelle décision doit être prise ; qui exécute cette décision et avec quoi ; et quel chiffre montrera que les choses se sont améliorées. Sans l'une de ces quatre réponses, un modèle ajoute une source de données de plus dont personne ne répond.
Là où l'IA n'est pas nécessaire. Si une règle peut s'écrire en une seule ligne — stock sous cinq unités, prévenir les achats — on l'écrit comme une règle : moins cher, prévisible et vérifiable ligne par ligne. L'IA a sa place là où il y a des dizaines de signaux, qu'ils changent avec le temps et qu'une personne décidait jusqu'ici à l'œil : classer une demande, estimer la demande, repérer une opération atypique, extraire des champs d'un document en texte libre.
| Tâche | Ce qui la résout |
|---|---|
| Prévenir les achats d'un stock faible | règle |
| Rattacher un e-mail entrant à un sujet et à un service | modèle |
| Appliquer une remise selon les conditions d'un contrat | règle |
| Estimer la demande d'un article à un mois | modèle |
| Vérifier que les champs obligatoires sont remplis | règle |
| Trouver une opération atypique parmi des opérations ordinaires | modèle |
La frontière passe par un seul critère : la condition peut-elle s'écrire en entier. Là où elle le peut, une règle travaille plus vite, coûte moins cher et explique elle-même sa décision. Un modèle est nécessaire là où la condition se décrit par des exemples et non par une ligne de texte. Dans un système qui fonctionne, les deux ne se concurrencent pas mais se tiennent côte à côte : le modèle met une entrée non structurée en forme, et les règles décident à partir de là.

Un pilote se construit sur des données historiques et se compare à la référence de départ sur ces mêmes données. Si le modèle ne bat pas la façon de travailler actuelle sur une période passée, il ne part pas en production.
Chaque direction ci-dessous est décrite par cette boucle. C'est aussi un moyen d'éprouver n'importe quelle proposition de mise en place d'IA : si elle ne nomme pas les quatre maillons, c'est une démonstration de possibilités et non un processus qui fonctionne.
Ce qui entre : commandes et paiements, demandes et correspondance, documents et scans, mouvements de marchandises, événements des équipements, écritures de la comptabilité. La source, la profondeur d'historique et la fréquence de mise à jour sont toutes énoncées.
Ce que fait le modèle : il range un objet dans une classe, extrait des champs, estime une valeur, trouve un écart par rapport à la norme, classe des options, formule une réponse à partir des documents trouvés. Toujours avec un chiffre de confiance.
Ce qu'il advient du résultat : la demande entre dans la file d'un exécutant, un statut change dans le CRM, une tâche atterrit à l'entrepôt, un document est validé, une réponse part vers le client, le cas passe à une personne.
Ce qui se mesure : le temps d'une opération, la part des décisions prises sans personne, le nombre d'erreurs et de reprises, les pertes dues aux retards et aux sorties de stock, la charge de l'équipe. La comparaison se fait avec la référence d'avant la mise en place.
La confiance de la classification était de 0,94 pour un seuil de 0,80. Sous le seuil, la demande serait partie dans la file générale avec un sujet proposé plutôt que directement au service qualité : un cas limite se traite par une personne et non par le modèle.
Données dans une entreprise se trouvent à des endroits différents et dans des états différents : une partie dans la base de la comptabilité, une partie dans les e-mails et les messageries, une partie dans des fichiers, une partie arrivant des équipements. Tant que la collecte se fait à la main, toute analyse décrit non pas l'entreprise mais ce que quelqu'un a réussi à exporter.
Traitement par l'IA : les entités sont extraites du flux — contrepartie, produit, document, événement ; les enregistrements portant sur un même objet sont reliés entre eux même quand les noms et les orthographes ne concordent pas. Rapprocher des noms, des adresses et des identifiants d'immatriculation est un travail de modèle et non de comparaison de chaînes.
Ce qui se raccorde :
Action : ce qui a été collecté entre dans un tampon de données brutes où rien n'est écrasé, et ne se répartit qu'ensuite vers les entrepôts de données, les modèles et les rapports. L'enregistrement d'origine peut toujours être retrouvé et vérifié.

Les données pour l'analytique et les modèles apparaissent sans exports manuels et sans une version du tableur dans chaque service. La collecte à la main passe du travail quotidien à l'exception, et les écarts entre rapports se règlent à partir du journal de chargement et non de ce dont les employés se souviennent.
Les données collectées ne sont pas prêtes à l'emploi : un même article porte trois noms différents, les unités de mesure sont mélangées, la moitié des enregistrements n'a pas d'attribut obligatoire, et certaines lignes sont des doublons d'une même opération. Un modèle entraîné sur un tel ensemble reproduira le désordre au lieu d'y trouver un schéma.
Traitement par l'IA couvre ici trois travaux : ramener les enregistrements à une forme unique, remplir les attributs là où il n'y en a pas, et ranger les objets dans des catégories qui n'existaient pas dans les données d'origine.
Action : les corrections sûres s'appliquent automatiquement et s'écrivent au journal avec la valeur d'origine ; les cas limites partent vers le propriétaire du référentiel pour confirmation, sous forme de liste unique et non d'e-mails séparés.
La qualité des données n'est pas un rangement ponctuel avant un projet mais un processus continu : les référentiels grandissent chaque jour, les fournisseurs changent le format de leurs tarifs, et les commerciaux créent des fiches de zéro au lieu de chercher celle qui existe. C'est pourquoi les règles et les modèles de nettoyage vivent dans le système à côté des données et s'appliquent à chaque chargement.
Chaque correction a un auteur — une règle ou un modèle —, une heure, une ancienne et une nouvelle valeur. Ce n'est pas de la bureaucratie : sans cet historique, il est impossible de comprendre pourquoi le rapport du mois dernier affiche aujourd'hui d'autres chiffres.
Les référentiels cessent de se ramifier, les rapports par groupe de produits et par poste de dépense concordent entre eux, et la préparation des données cesse de dévorer l'essentiel du calendrier de chaque projet d'analytique.
| Vérification | Lignes | Résultat |
|---|---|---|
| Rapprochées du catalogue | 4 812 | appliqué |
| Unités de mesure normalisées | 1 106 | appliqué |
| Catégorie remplie d'après la description | 438 | appliqué |
| Fiches semblables, décision nécessaire | 96 | en attente d'examen |
| Incohérences dans le document | 14 | retour au fournisseur |
Une capture du système : les chiffres sont illustratifs. Seuls les cas sous le seuil de confiance partent à l'examen — 96 lignes sur 6 466 ; le reste a été appliqué automatiquement, la valeur précédente étant écrite au journal.
Un rapport ordinaire répond à la question qu'on lui a posée : recette par mois, ventes par succursale, stocks par entrepôt. Les questions sont posées par une personne : on voit donc exactement ce que quelqu'un a pensé à regarder.
Traitement par l'IA renverse ici le sens : le modèle passe lui-même en revue les découpages et rapporte ceux où un indicateur se comporte autrement qu'attendu. Non pas « dessine-moi un graphique » mais « voici trois endroits où il se passe quelque chose d'inhabituel, et voici avec quoi cela va de pair ».
Ce que fait l'analytique intelligente :
Action : une trouvaille ne reste pas dans un tableau de bord — elle se transforme en tâche avec un destinataire et un délai : examiner le point en baisse, contacter le client du groupe à risque, vérifier la catégorie dont les retours augmentent.

Un modèle montre une corrélation, pas une cause. Une hausse des retours dans une catégorie peut s'expliquer par un lot défectueux, un changement de fournisseur, une erreur dans la description du produit ou un nouveau canal de vente au public différent — choisir l'explication et prendre la décision reste à une personne.
C'est pourquoi chaque trouvaille s'accompagne dans l'interface de trois choses : sur quelles données elle est construite, quelle est l'ampleur de l'écart et quels découpages le modèle a vérifiés. Une conclusion qui ne se déplie pas jusqu'aux lignes d'origine ne donne lieu à aucune action.
L'analytique cesse d'être un rapport mensuel lu après la clôture de la période. Un écart se trouve le jour même, s'examine tant que la piste est chaude et coûte moins cher que lorsqu'il se remarque dans une vue trimestrielle.
Une anomalie n'est pas n'importe quelle valeur rare mais un écart par rapport à la norme propre d'un objet. Pour un point de vente, vingt tickets à l'heure est une journée ordinaire ; pour un autre, c'est une raison de vérifier. La norme se calcule à partir de l'historique de chaque objet et d'un groupe comparable, et non d'une moyenne générale.
Données : l'historique de l'indicateur pour l'objet. Traitement : le modèle construit un couloir attendu tenant compte du jour de la semaine, de la saison et des promotions. Action : la sortie du couloir crée une tâche d'examen. Résultat : un creux de ventes ou une panne comptable se voit le jour même.
Données : paiements, remises, retours, annulations, modifications manuelles de documents. Traitement : une combinaison d'attributs est évaluée — montant, heure, employé, fréquence. Action : l'opération entre dans la file de contrôle. Résultat : les abus et les erreurs se traitent avant la clôture de la période.
Données : la télémétrie des appareils et des bornes. Traitement : on cherche un changement du caractère des événements avant une panne. Action : l'appareil est ajouté à une tournée technique. Résultat : une partie des pannes se traite avant l'immobilisation et non après une réclamation.
Données : écritures, stocks, inventaires, transferts. Traitement : les flux censés concorder se rapprochent les uns des autres. Action : un écart se consigne avec un responsable. Résultat : les manquants se remontent à un endroit précis et non à une somme globale en fin de trimestre.
Données : l'historique des commandes, des demandes et des paiements. Traitement : le modèle remarque une rupture du rythme d'achat habituel. Action : le client atterrit sur une liste pour le commercial. Résultat : le départ d'un client se voit avant qu'il n'ait cessé d'acheter pour de bon.
Données : les heures des étapes d'une commande, d'une demande, d'une réparation. Traitement : les étapes dont la durée grandit et leurs attributs sont identifiés. Action : l'étape est soulevée pour examen, chiffres à l'appui. Résultat : les délais se raccourcissent là où le temps se perd réellement.
| Objet | Ce qui ne va pas | Attendu | Physique | État |
|---|---|---|---|---|
| Point n° 14 | Recette sous le couloir pour le troisième jour | 98–126 mille | 61 mille | examen |
| Entrepôt « Ioujny » | Part des corrections manuelles de stock | jusqu'à 1,5 % | 6,2% | examen |
| Borne T-207 | Pannes croissantes du module de paiement | 0–2 par jour | 17 | en tournée |
| Catégorie produits d'entretien | Retours au-dessus de la norme de la catégorie | jusqu'à 2,1 % | 5,8% | en attente |
Une capture du système : les chiffres sont illustratifs. Chaque ligne se déplie jusqu'aux opérations d'origine — un écart qui ne se remonte pas jusqu'aux données primaires n'entre jamais dans la file.
Planifier d'après le mois précédent se trompe de façon prévisible : cela ne sait rien de la saison, rien de la promotion, et rien du fait que l'article a été en rupture pendant deux semaines, ce qui explique l'absence de ventes — et non l'absence de demande.
Données : l'historique des ventes par article et par point, les périodes de rupture, les prix et les promotions, le calendrier — week-ends, jours fériés, rentrée scolaire —, la météo là où elle influe sur la demande, et les données de livraisons et de délais.
Traitement par l'IA : le modèle estime la demande future pour chaque couple article-point et montre la dispersion à part : non pas un nombre unique mais une fourchette avec une probabilité. Pour la planification des stocks, c'est la borne haute qui compte le plus ; pour la planification de la recette, la valeur centrale.
Ce qui se prévoit :
Action : une prévision ne reste pas une note — elle alimente la demande d'achat, le plan de réapprovisionnement des points, le planning des équipes et les limites de crédit des clients. Résultat : moins de ventes perdues faute de marchandise en rayon et moins d'argent immobilisé en stock excédentaire.

Un modèle ne s'éprouve pas sur les données dont il a appris : l'historique se coupe dans le temps, l'apprentissage se fait sur le segment antérieur et la vérification sur le segment postérieur. Cela reproduit la situation réelle, dans laquelle l'avenir est inconnu.
L'exactitude se mesure en continu et non une fois au lancement : chaque ligne de prévision se compare au réel à la clôture de la période. Une erreur qui augmente est un signal : le comportement de la demande a changé et le modèle est bon pour un réapprentissage.
Une capture du système : les chiffres sont illustratifs. Les groupes à forte erreur ne sont pas cachés mais montrés à part : pour ceux-là, la commande se calcule par une personne, à partir de la fourchette et non d'un nombre unique.
Le travail courant, ce sont les opérations qui se répètent des dizaines de fois par jour, demandent de l'attention et ne demandent aucune qualification : recopier des données d'un e-mail dans une fiche, rattacher un paiement à un poste de dépense, désigner un exécutant, vérifier qu'un document est complet, poser un statut.
Traitement par l'IA est nécessaire là où l'entrée n'est pas formalisée : l'e-mail est écrit en toutes lettres, le document est arrivé dans un format qui n'est pas le vôtre, la demande est formulée différemment par chaque client. Le modèle met une telle entrée en forme, après quoi des règles ordinaires — prévisibles et vérifiables — prennent le processus en charge.
Les opérations qui deviennent automatiques :
Action et résultat : l'opération est exécutée par le système et écrite au journal avec un auteur, une heure et la valeur d'origine. L'employé passe de la saisie de données au traitement des cas particuliers — ceux où le modèle n'est pas sûr ou où le coût d'une erreur est élevé.

Une action automatique est permise là où elle peut se défaire ou là où une erreur coûte peu : poser un statut, affecter un exécutant, créer un brouillon. Les opérations irréversibles — mouvements d'argent, validation d'un document, expédition de marchandises — restent à une personne ou demandent une confirmation.
Le seuil de confiance se pose séparément pour chaque opération et change à mesure que les statistiques s'accumulent. Les entreprises commencent d'habitude par un seuil élevé et un mode « proposition » : le modèle propose, une personne confirme — et ces confirmations montrent où l'on peut lui faire confiance.
Données : bons de livraison, factures, attestations, contrats, spécifications, ordres de paiement, demandes, fiches techniques d'équipements, e-mails avec pièces jointes. Les formats varient : pdf, photo prise au téléphone, scan, fichier d'export, original papier.
Traitement par l'IA : reconnaissance du texte, identification du type de document, extraction des champs et des tableaux, rapprochement des lignes avec le catalogue et rattachement du document à une commande, un contrat ou une contrepartie. Pour chaque champ, une valeur et un chiffre de confiance sont renvoyés.
Ce qui est extrait :
Action : le document se rapproche de la commande et de la facture, les écarts sont listés, et le document est soit validé, soit envoyé à l'examen d'un employé précis. Résultat : la saisie des documents cesse d'être un métier à part entière, et les écarts se trouvent avant le paiement et non à la clôture du mois.
La reconnaissance ne donne jamais cent pour cent d'exactitude sur un ensemble de documents quelconque — et cela ne doit pas être le cas. L'enjeu est ailleurs : le système montre les champs auxquels il fait confiance et ceux qu'il demande de confirmer. L'opérateur vérifie quelques champs signalés au lieu de taper tout le document.
Une mauvaise qualité de la source n'excuse pas une erreur silencieuse : une photo floue, une page coupée, la deuxième page manquante d'une spécification sont toutes signalées explicitement et renvoyées à l'expéditeur avec le motif.
La vitesse de traitement cesse de dépendre du volume du flux entrant, et la comptabilité et les achats voient l'état des documents dans une seule liste plutôt que dans les boîtes aux lettres de chacun.
Une capture du système : les chiffres sont illustratifs. Le document n'est proposé à la validation qu'une fois les deux signalements traités — un nouvel article de catalogue et un manquant demandent tous deux une confirmation humaine.
Données : e-mails, demandes venues du site, messages dans les messageries, transcriptions d'appels, correspondance du chat de support, avis et notes. Tout cela est du texte libre qu'une personne devait jusqu'ici lire et trier.
Traitement par l'IA : la demande se range dans un sujet et un sous-sujet, l'urgence et la tonalité sont déterminées, le numéro de commande, le nom du produit, l'adresse et d'autres entités sont extraits du texte, et la demande se relie à l'historique du client. Les demandes répétées sur un même sujet se fondent en un seul cas.
Action : la demande entre dans la file du groupe concerné avec ses champs déjà remplis, le délai de réponse se calcule d'après l'urgence, une demande répétée monte en priorité, et le client reçoit une confirmation avec un numéro et un délai attendu.
Résultat : les demandes cessent de dormir dans une boîte commune jusqu'au matin, et le responsable ne voit pas « beaucoup de réclamations » mais une structure : sur quels sujets le flux grandit, où le temps de réponse augmente et quels produits engendrent des demandes répétées.
Une demande isolée renseigne sur un cas ; tout le flux renseigne sur le produit et sur le processus. La classification par sujet sur une période montre ce qui pose exactement question : une notice peu claire, une erreur dans la description d'un produit, une panne à une étape précise de la validation de commande, un retard chez un service de livraison.
C'est pourquoi les sujets ne s'inventent pas : les demandes se regroupent d'abord par sens automatiquement, puis les groupes obtenus se corrigent à la main et se figent comme référentiel. À partir de là, il vit à côté du produit, et les nouveaux groupes sont proposés par le système.
| Sujet | Part | Évolution | Première réponse |
|---|---|---|---|
| Statut et délais de livraison | 31% | −4% | 6 min |
| Paiement et remboursements | 22% | +9% | 18 min |
| Disponibilité et caractéristiques des produits | 19% | −1% | 4 min |
| Problèmes d'espace client | 15% | +6% | 27 min |
| Réclamations qualité | 13% | 0% | 41 min |
Une capture du système : les chiffres sont illustratifs. Les deux sujets en hausse — le paiement et l'espace client — ne partent pas dans un rapport mais dans la liste de travail de l'équipe produit, avec des exemples de demandes en pièce jointe.
Une recommandation est utile là où le choix est large et l'attention courte : un catalogue de dizaines de milliers d'articles, l'assortiment d'un point, un ensemble de services, une courte liste pour un commercial avant un appel. Les données qui la portent sont l'historique des commandes, les consultations, le contenu du panier, les retours et les stocks ; le résultat doit toujours tenir compte de la disponibilité, sinon le système recommande ce qui n'existe pas.
Traitement : des associations stables d'articles sont identifiées à partir de l'historique des commandes. Action : la sélection s'affiche sur la fiche produit et dans le panier. Résultat : le nombre de lignes par ticket grandit sans forcer la main à l'acheteur.
Traitement : le modèle estime la probabilité d'intérêt pour un article à partir de l'historique du client et de clients semblables. Action : l'offre part vers son espace, vers une campagne ou vers un commercial. Résultat : le taux de réponse est plus élevé que pour un envoi général, et la fréquence des contacts plus basse.
Traitement : la requête s'analyse par le sens et non par la correspondance des lettres : synonymes, fautes de frappe et caractéristiques sont pris en compte. Action : les résultats se réordonnent. Résultat : moins de recherches sans résultat et moins de gens qui quittent le catalogue.
Traitement : les ventes de points comparables et leur environnement se confrontent. Action : un article est proposé au retrait de l'assortiment ou à l'ajout. Résultat : le rayon est occupé par ce qui se vend réellement ici.
Traitement : avant un contact, l'historique du client, les questions ouvertes et les articles adaptés sont rassemblés. Action : la courte liste apparaît sur la fiche du CRM. Résultat : préparer un appel prend une minute et non dix.
Traitement : la date attendue d'un rachat d'un consommable est estimée. Action : un rappel part à cette date. Résultat : moins de commandes répétées manquées et moins de contacts inutiles.
La personnalisation est bornée par des règles explicites : ce qu'il ne faut pas recommander, quelles données ne sont pas utilisées, à quelle fréquence on peut contacter un client et comment il désactive la sélection. Les limites se posent dans le système et ne restent pas un accord verbal.
La vision par ordinateur se justifie dans une classe étroite de tâches : la scène se répète, l'objet se distingue, et le résultat se transforme directement en événement de gestion. Là où ces trois conditions ne sont pas réunies, une caméra donne une archive vidéo et des fausses alertes, et non de l'automatisation.
Là où cela fonctionne :
Action : un événement reconnu ne part pas dans une archive mais dans les écritures — dans un ticket, une tâche, un procès-verbal de réception, un journal des infractions. Résultat : la consignation manuelle de ce que la caméra voit déjà disparaît.

Les tâches où la scène est différente à chaque fois, où l'éclairage est quelconque et où le coût d'une erreur est élevé ne se couvrent pas par des caméras. La reconnaissance des émotions, l'évaluation de la conscience professionnelle d'un employé, l'identification de personnes dans une foule quelconque — tout cela est soit peu fiable, soit encadré par la loi, soit les deux.
Là où c'est l'exactitude qui compte et non l'image, d'autres capteurs travaillent moins cher et plus sûrement : un poids, un lecteur de codes-barres, une étiquette, une serrure à journal. Une caméra s'ajoute à eux plutôt qu'elle ne les remplace.
Un bot IA diffère d'un chatbot à scénario sur un point : il ne promène pas l'utilisateur dans un arbre de boutons mais comprend la question et exécute une action dans un système. La valeur n'est pas ici dans la conversation mais dans les données et les opérations auxquelles le bot est raccordé — catalogue, commandes, demandes, CRM, base de connaissances. Un bot sans accès aux systèmes ne sait que reformuler le manuel.

Données : le catalogue, les prix, les stocks, les conditions de livraison et de paiement, les statuts de commande. Traitement : la question s'analyse par le sens et la réponse s'assemble à partir de données du moment et non d'un texte préparé. Action : choisir un article, calculer une livraison, passer ou modifier une commande. Résultat : les questions courantes se traitent 24 heures sur 24 pendant que les commerciaux s'occupent des questions complexes.
Données : la base de solutions, l'historique des demandes, la configuration du client, les journaux du système. Traitement : le symptôme se rapproche de cas connus. Action : des instructions pas à pas, une vérification de statut, la création d'un ticket avec les données déjà rassemblées. Résultat : la première ligne clôt les cas répétés et l'ingénieur reçoit un ticket avec le diagnostic déjà fait.
Données : les politiques, les décisions, les instructions, les référentiels et les rapports accessibles à l'employé selon ses droits. Traitement : une recherche par le sens et une réponse avec la référence à l'article du document. Action : déposer une demande aux RH ou aux achats, demander une attestation, solliciter une validation. Résultat : les questions aux collègues et dans les conversations de groupe sont remplacées par une réponse avec sa source.
Données : le texte de la demande, les pièces jointes, l'historique du client. Traitement : détermination du type de demande, extraction des champs, contrôle d'exhaustivité. Action : la demande se crée dans le système, les données manquantes sont réclamées, un exécutant est affecté. Résultat : la demande parvient complète à l'exécutant, sans allers-retours pour clarifier.
Données : fiches clients, affaires, tâches, historique des contacts. Traitement : analyse de la demande du commercial et de l'issue de l'échange. Action : créer et mettre à jour une fiche, consigner l'issue d'un contact, poser une tâche, rassembler un résumé sur un client avant un appel. Résultat : le CRM se remplit au fil du travail et non le soir, de mémoire.
Données : contrats, spécifications, politiques, documentation technique, archive de correspondance. Traitement : une recherche par le sens au lieu d'une correspondance de mots ; la réponse se construit à partir des fragments trouvés. Action : une réponse avec une citation et une référence au document, à la page et à la version. Résultat : répondre à une question sur un contrat prend quelques secondes et se vérifie sur la source.
Un bot n'est pas un modèle unique mais plusieurs parties reliées. La séparation compte en pratique : chaque partie a son mode de défaillance, ses indicateurs et sa façon d'être corrigée.
Les canaux de raccordement — le site et l'espace client, les messageries, l'e-mail, une ligne téléphonique avec reconnaissance vocale, le portail interne et les postes de travail des employés. La logique est la même partout : le canal change la forme de l'entrée, pas ce que le bot a le droit de faire.
Le bot ne retient pas vos documents — il les cherche au moment de la question et répond à partir de ce qu'il trouve. C'est pourquoi une politique mise à jour prend effet dès son chargement et non après un réapprentissage du modèle, et c'est pourquoi chaque réponse a une source.
L'étape 2 est obligatoire : le bot répond dans les limites des droits de celui qui a demandé. Un document auquel l'employé n'a pas accès dans le système n'entre ni dans la recherche ni dans la citation — sinon le bot devient un moyen de contourner le système d'accès.
La première chose que l'on rassemble est un ensemble de questions réelles — venues de la correspondance, des demandes et des conversations internes. Le bot s'éprouve dessus avant le lancement : les réponses se vérifient sur les sources et les erreurs s'examinent par cause. Ce n'est qu'ensuite que le bot s'ouvre aux utilisateurs, d'habitude d'abord à un seul groupe.
Le risque principal d'un bot IA est une réponse fausse énoncée avec assurance. Il ne s'écarte pas par des promesses mais par la façon dont le système est construit : un ensemble limité d'opérations, un ancrage obligatoire dans les sources, des seuils de confiance et des règles d'escalade explicites.
Le bot ne fait que ce qui est décrit dans son jeu d'actions, et dans les limites des droits de celui qui a demandé. Tout le reste est indisponible, aussi insistant que soit l'utilisateur.
La réponse s'assemble à partir des documents trouvés et des données des systèmes. S'il n'y a pas de source, le bot dit qu'il ne sait pas et transmet la question — c'est un comportement normal et non une panne.
Sous le seuil, la réponse ne part pas vers le client : elle va vers un opérateur sous forme de brouillon, avec les documents trouvés. Chaque sujet a son propre seuil.
Escalade selon des règles : sujet réservé, question répétée, réaction négative, demande du client. L'opérateur reçoit tout l'échange et les documents trouvés au lieu de repartir de zéro.
Une action irréversible — annuler une commande, changer des coordonnées bancaires, sortir quelque chose du stock — ne s'exécute qu'après une confirmation explicite et s'écrit au journal avec son initiateur.
La part des échanges clos sans humain, la part des escalades, les notes des utilisateurs et des vérifications par sondage des réponses. Les erreurs reviennent dans l'ensemble des questions de test.
Ce que le bot dit de lui-même se consigne à part : l'utilisateur doit comprendre qu'il parle à un logiciel et savoir comment appeler une personne. C'est une exigence pour l'interface et non une affaire de réglages.
Un assistant interne diffère d'un bot pour clients par ses données sources : il travaille sur l'information de l'entreprise et dans les limites des droits d'un employé précis. La même question posée par un magasinier et par un directeur financier donne des réponses différentes — parce qu'ils n'ont pas accès aux mêmes documents.
Ce que fait un assistant à un poste de travail :
Résultat : l'employé passe son temps sur le travail plutôt qu'à chercher le bon document, à se rappeler une politique et à remplir des formulaires. L'assistant ne prend pas de décision à la place de la personne — il enlève la partie préparatoire.

L'assistant se raccorde aux mêmes rôles que les systèmes de gestion : il ne crée pas un chemin d'accès parallèle. Les documents hors des droits d'un employé n'entrent ni dans la recherche, ni dans les citations, ni dans les suggestions — et cela se vérifie avant que la réponse ne se compose, et non après.
Les actions de l'assistant entrent dans le journal général du système, à côté de celles des personnes. Sur une fiche, on voit que la tâche a été créée par l'assistant à la suite d'un échange, plutôt qu'un enregistrement apparu sans auteur.
Les connaissances d'une entreprise sont rarement au même endroit : les politiques dans un dossier, les contrats dans un deuxième, la documentation technique dans un troisième, et la moitié des réponses dans la correspondance. La recherche par nom de fichier ne fonctionne pas ici, car une personne ne cherche pas un document mais une réponse.
Données : politiques et décisions, contrats et annexes, documentation technique et de projet, instructions, base des demandes résolues, comptes rendus, référentiels, archive de correspondance — chacun avec un propriétaire et un niveau d'accès.
Traitement par l'IA : les documents se découpent en fragments et chaque fragment s'indexe par le sens ; la question se rapproche des fragments et non des titres. La réponse s'assemble à partir de ce qui a été trouvé et s'accompagne d'une citation et d'une référence au document, à la page et à la version.
Action et résultat : un employé obtient une réponse avec sa source en quelques secondes au lieu de faire le tour de ses collègues ; les cas limites se vérifient sur la citation ; les documents périmés se voient tout de suite — si la réponse vient d'une version vieille de deux ans, cela est indiqué dans la réponse elle-même.
Elle ne remplace pas le système de gestion documentaire et ne devient pas la source de vérité : un document à valeur juridique reste là où il a été signé et se conserve. L'index est un moyen de le trouver et de le citer, et non une copie à part vivant sa propre vie.
Une demande arrive en forme libre et par n'importe quel canal : un e-mail, un message, un formulaire du site, un appel téléphonique, un fichier joint. Avant la mise en place, une personne la lit, reporte les données dans le système, détermine le type et affecte un exécutant — ce qui prend de quelques minutes à quelques heures d'attente dans une file.
Traitement par l'IA : le type de la demande est déterminé, les champs sont extraits — objet, adresse, délai, contact, numéro de contrat —, l'exhaustivité est contrôlée, l'urgence est évaluée, et la demande se relie au client et à son historique. Ce qui manque est réclamé automatiquement dans le même canal.
Action : la demande se crée dans le système avec ses champs remplis, un groupe ou un exécutant est affecté selon les règles, un délai est fixé et une confirmation avec un numéro est envoyée. Les doublons portant sur un même sujet se relient au lieu d'engendrer une seconde demande.
Résultat : l'exécutant reçoit une demande complète et commence par le travail plutôt que par des clarifications. Le temps entre l'arrivée et l'affectation cesse de dépendre de qui a ouvert la boîte commune et quand.
Une capture du système : les données sont illustratives. Les demandes dont le type a été déterminé avec une confiance sous le seuil parviennent au régulateur avec les champs pré-remplis et un type proposé — l'affectation reste à une personne.
Données
Analytique et prévision
L'automatisation
Bots et assistants
Un modèle n'est utile que lorsque sa décision parvient au système où le travail se fait. C'est pourquoi l'intégration n'est pas la dernière étape d'un projet mais sa condition préalable : on sait d'abord où le résultat atterrira, ensuite on entraîne le modèle.
Ce à quoi la couche IA se raccorde :
Le mode de raccordement se choisit selon le système et non par habitude : une API directe, un échange par file, des webhooks sur événement, des exports de fichiers programmés, la lecture d'un réplica de base. Pour les systèmes sans interface ouverte, on utilise le mode d'échange dont ils disposent, fichiers compris.

| Heure | Opération | Résultat |
|---|---|---|
| 11:02 | Classification des demandes → CRM | 148 |
| 11:05 | Prévision de la demande → demande d'achat | 1 204 |
| 11:07 | Analyse des bons de livraison → comptabilité | 6 à examiner |
| 11:09 | Le service d'entrepôt est indisponible | nouvelle tentative dans 5 min |
Une capture du système : les chiffres sont illustratifs. L'indisponibilité de l'entrepôt n'arrête pas les autres échanges — les messages attendent dans la file et partent au rétablissement de la liaison.
Mettre en place l'IA, c'est travailler sur les données de l'entreprise : la question de savoir où le modèle tourne et ce qui sort du périmètre se règle donc avant le début du projet et non après le lancement.
L'environnement se choisit selon la sensibilité des données : votre propre infrastructure, un serveur dédié ou un service extérieur. Pour certaines tâches, des modèles ouverts sur votre propre matériel couvrent entièrement le besoin.
Si un modèle extérieur est utilisé, l'ensemble des champs transmis est décrit explicitement. Les données personnelles et les conditions commerciales sont anonymisées ou remplacées par des identifiants avant l'envoi.
La couche IA travaille dans les limites des droits de l'utilisateur et ne crée pas de porte dérobée vers les données. Le contrôle d'accès se fait avant la recherche et avant la composition de la réponse.
La demande, les sources trouvées, la décision du modèle et l'action réalisée s'écrivent toutes au journal. Sans cela, il est impossible d'examiner un cas contesté comme de démontrer que le système a travaillé correctement.
Les décisions à conséquences juridiques ou financières restent à une personne. Le modèle prépare la matière et propose une possibilité, et la confirmation se consigne avec son auteur.
Les durées de conservation des échanges, des jeux d'apprentissage et des données intermédiaires se fixent à l'avance. La suppression sur demande s'étend aussi aux index de recherche, et pas seulement à la base d'origine.
Un modèle se trompe toujours — la question est de savoir à quelle fréquence, où exactement et ce que cela coûte. C'est pourquoi chaque mise en place a deux séries de chiffres : la qualité du modèle lui-même et le changement du processus. La première intéresse l'ingénieur, la seconde l'entreprise, et elles ne coïncident pas automatiquement.
Le seuil de confiance est un bouton de réglage, pas une constante. En le montant, l'entreprise obtient moins d'automatisation et moins d'erreurs ; en le baissant, l'inverse. La valeur se choisit d'après le coût d'une erreur dans le processus en question.
Une capture du système : les chiffres sont illustratifs. Les trois indicateurs ne se lisent qu'ensemble : plus d'automatisation avec une part de corrections en hausse veut dire que le seuil a été trop baissé.
Un modèle n'est pas une livraison ponctuelle. Les données changent : de nouveaux produits, de nouveaux sujets de demandes, de nouveaux formats de documents, de nouveaux fournisseurs apparaissent. C'est pourquoi le projet prévoit des contrôles de qualité réguliers sur des données fraîches, un réapprentissage selon un calendrier ou au franchissement d'un seuil, et l'examen des cas où une personne a corrigé la décision.
Les corrections des opérateurs sont la matière d'apprentissage la plus précieuse : elles se rassemblent dans un jeu à part et servent au tour d'apprentissage suivant. Ainsi le système s'améliore sur son propre travail et non sur les données d'autrui.
L'ordre reflète les dépendances : chaque étape s'appuie sur ce qui est apparu à la précédente. Sauter la première étape est la raison la plus fréquente pour qu'un projet d'IA se termine en démonstration.
Quelle opération est automatisée, qui l'exécute aujourd'hui, quelles données existent et dans quel état, où le résultat atterrira. Le résultat est une référence de départ chiffrée et un critère de réussite.
Raccordement des sources, nettoyage et annotation, un entrepôt de données pour la tâche. C'est aussi là que l'on voit s'il y a assez d'historique pour un modèle ou s'il faut d'abord accumuler des données.
Apprentissage et vérification sur une période mise de côté, comparaison à la référence de départ, lancement en mode « proposition » sur une partie du flux. Le seuil de confiance se règle sur les décisions réelles des opérateurs.
Intégration avec les systèmes, droits et journaux, surveillance de la qualité et de la dérive, réapprentissage selon un calendrier, accompagnement. L'extension aux processus voisins vient comme des étapes à part, avec mesure.
Décrivez le processus que vous voulez automatiser et les données déjà collectées à son sujet. Nous vous dirons ce qui peut se résoudre ici par des règles et de l'intégration et là où un modèle est réellement nécessaire.