Ce qu'un dirigeant peut faire lui-même avec l'IA

En bref. Avant de lancer un projet d'IA à l'échelle de l'entreprise, le dirigeant doit d'abord expérimenter lui-même quelques usages simples : analyser un tableau de bord avec un modèle de langage, automatiser une tâche répétitive via un workflow low‑code, tester un assistant de rédaction sur un compte‑rendu, vérifier la pertinence d'un classement de prospects avec un petit modèle, et enfin décider, en connaissance de cause, où l'IA n'apporte rien ou crée des risques. Cette pratique personnelle construit le jugement nécessaire pour orienter les investissements futurs.

Une situation concrète : le tableau de bord qui ne parle pas

Lors de la revue mensuelle des performances commerciales, la directrice remarque que le temps consacré à la consolidation des chiffres de vente a augmenté de près de quinze pour cent depuis le trimestre précédent. L’équipe explique que le nouveau chatbot interne, censé répondre aux questions simples sur les produits, génère des réponses parfois imprécises, obligeant les collaborateurs à vérifier chaque information manuellement. Au lieu de poursuivre le déploiement du chatbot à l’échelle de l’entreprise, elle décide de prendre elle‑même en main le problème : elle extrait un échantillon de cinquante factures au format PDF, les charge dans un notebook Jupyter et utilise le modèle GPT‑4o via son API pour en tirer les montants, les dates et les références clients. En moins de dix minutes, elle obtient un tableau structuré qu’elle compare à celui produit manuellement. L’écart se situe autour de trois pour cent, principalement dû à des mentions manuscrite mal reconnues. Cette expérimentation lui montre que le modèle de langage peut accélérer la saisie, mais qu’il nécessite une étape de validation lorsqu’il traite des documents non structurés.

Usage 1 : interroger un modèle de langage sur ses propres données

Un dirigeant peut commencer par poser des questions directement à un modèle de langage sur des jeux de données internes qu’il connaît bien : les chiffres du tableau de bord Excel, les fiches clients du CRM ou les historiques de tickets du service support. Par exemple, en utilisant l’interface de Claude 3 avec un fichier CSV de deux mille lignes contenant le chiffre d’affaires mensuel par région, il demande : « Quelle région a connu la plus forte croissance au cours des six derniers mois ? » Le modèle répond en quelques secondes, en citant le pourcentage exact et en montrant le calcul sous‑jacent. Cette approche ne nécessite aucun développement ; il suffit de copier‑coller les données dans la zone de texte ou de passer par un petit script qui envoie le fichier via l’API. L’intérêt réside dans la rapidité d’obtention d’une première insight, qui peut ensuite être confrontée aux analyses habituelles pour vérifier la cohérence.

Usage 2 : automatiser une tâche répétitive avec un workflow low‑code

La deuxième expérimentation consiste à mettre en place un flux automatisé qui élimine une étape manuelle récurrente, sans écrire de code complexe. À l’aide de n8n, le dirigeant crée un workflow qui surveille une boîte mail dédiée aux demandes de devis. Lorsqu’un nouveau message arrive, le workflow :

1. extrait le texte du corps du courriel grâce à un nœud de traitement de langage naturel basé sur Mistral 7B,
2. interroge le CRM (HubSpot) pour vérifier si l’expéditeur existe déjà,
3. crée une fiche de prospect si nécessaire,
4. envoie une notification Slack au commercial responsable.

Après une semaine de test, le dirigeant constate que le temps moyen de traitement d’une demande passe de huit minutes à moins de deux minutes, tout en maintenant un taux d’erreur inférieur à un pour cent (principalement lié à des pièces jointes illisibles). Il note toutefois que le workflow échoue lorsqu’il reçoit des courriels rédigés dans un langage très familier ou avec des abréviations propres à certains secteurs ; dans ces cas, il faut intervenir manuellement pour corriger l’extraction avant de poursuivre le flux. Cette expérience lui montre où l’automatisation low‑code apporte un gain réel et où elle nécessite encore une supervision humaine.

Usage 3 : assister la rédaction de comptes‑rendus

Un troisième usage personnel porte sur la préparation des comptes‑rendus de réunion. Le dirigeant utilise l’assistant de rédaction intégré à son traitement de texte (par exemple, l’extension « Write with AI » basée sur Claude) pour transformer ses notes brutes en un texte structuré. Il commence par copier‑coller ses points clés – généralement une vingtaine de phrases décousues – et demande au modèle de produire un compte‑rendu comportant : un rappel de l’ordre du jour, les décisions prises, les actions attribuées et les échéances. En moins de deux minutes, il obtient un texte qu’il relit rapidement pour vérifier la fidélité aux propos tenus. Il remarque que le modèle a tendance à généraliser certaines déclarations lorsqu’elles sont formulées de façon implicite ; il doit donc rétablir les nuances manquantes. Cette expérimentation lui permet de juger de la valeur ajoutée d’un assistant de rédaction pour des documents internes où le ton doit rester factuel et où la confidentialité des échanges est primordiale.

Usage 4 : tester un classement de prospects et reconnaître ses limites

Enfin, le dirigeant souhaite voir si un petit modèle de classement peut l’aider à prioriser ses prospects commerciaux. Il prend un jeu de données de cinq cents leads issus du CRM, comprenant des variables telles que le secteur d’activité, la taille de l’entreprise, le nombre de interactions récentes et le historique d’achat. À l’aide de la plateforme Make, il entraîne un modèle de régression logistique simple (exporté depuis un notebook Python) qui renvoie une probabilité de conversion. Il compare ensuite le classement obtenu avec celui basé sur la règle actuelle (« les leads provenant du secteur technologique sont prioritaires »). Sur un échantillon de cent leads, le modèle identifie trente leads à fort potentiel que la règle actuelle aurait classés comme moyens, tandis qu’il relègue vingt leads que la règle considérait comme prioritaires mais qui présentent peu d’interactions récentes. Le dirigeant conclut que le modèle apporte une perspective différente, mais il relève deux limites importantes : premièrement, la qualité du résultat dépend fortement de la complétude des données – les leads avec des champs manquants voient leur score biaisé ; deuxièmement, le modèle ne tient pas compte de facteurs externes tels que les changements réglementaires récents qui peuvent soudainement rendre un secteur plus attractif. Fort de cette analyse, il décide de ne pas remplacer la règle existante par le modèle seul, mais de l’utiliser comme un complément de réflexion lors des réunions de pilotage.

Quand ne pas déployer : l’automatisation totale de la décision de crédit

Un cas où la réponse est clairement « ne le faites pas » concerne l’automatisation complète de l’octroi de crédit aux clients professionnels. Le dirigeant teste un pipeline qui, à partir du bilan financier d’une entreprise fourni en PDF, extrait les ratios d’endettement et de liquidité grâce à un modèle de langage, puis applique un seuil prédéfini pour approuver ou refuser la demande. Après cent simulations, il constate que le système approuve vingt‑cinq pour cent des demandes qui, selon l’analyse manuelle d’un analyste senior, présenteraient un risque de défaut élevé, principalement parce que le modèle ne saisit pas les notes de bas de page détaillant des éventuels litiges en cours. En outre, le pipeline ne fournit aucune explication lisible pour le refus, ce qui contrevient à l’obligation de motivation prévue par le code de la consommation. Le dirigeant conclut que, dans ce contexte, l’IA peut servir d’aide à la décision – par exemple, en mettant en évidence les ratios anormaux – mais qu’elle ne doit pas être la seule autorité de jugement. Il décide donc de maintenir une étape de validation humaine systématique avant toute finalisation.

Après avoir mené ces expérimentations, le dirigeant dispose désormais d’une base concrète pour discuter avec ses équipes techniques et financières. La prochaine étape consiste à définir, avec le responsable IT, un protocole de test de deux semaines pour un cas d’usage prioritaire – par exemple, l’enrichissement automatisé des fiches prospects via n8n – en fixant clairement les critères de succès (gain de temps, taux d’erreur acceptable) et les conditions d’arrêt (détection de biais ou de non‑conformité). Cette approche permet de passer de la promesse à la preuve, tout en limitant les engagements prématurés.

Questions fréquentes

Quel temps réel devrais-je consacrer à ces expérimentations personnelles ?

Un dirigeant peut commencer par bloquer deux à trois heures réparties sur une semaine pour chaque usage présenté. Par exemple, trente minutes pour préparer les données et interroger le modèle de langage, puis une heure pour mettre en place un petit workflow dans n8n, suivi d’une revue des résultats. L’objectif n’est pas de devenir un expert technique, mais de disposer d’un retour d’expérience suffisamment riche pour orienter les discussions avec les équipes spécialisées.

Faut-il investir dans une licence coûteuse d’un modèle de langage avant de tester ?

Non. La plupart des fournisseurs proposent un accès gratuit ou à faible coût pour un volume limité de requêtes, suffisant pour des essais sur quelques centaines de lignes de données ou quelques dizaines de documents. Par exemple, l’API de GPT‑4o offre un crédit d’exploration qui permet de traiter plusieurs milliers de tokens sans frais initiaux, tandis que Mistral fournit un accès ouvert via Hugging Face pour des tests locaux. Il est donc possible de valider l’intérêt avant d’engager un budget récurrent.

Comment m’assurer que les données utilisées lors de mes tests restent confidentielles ?

Il convient de travailler sur des copies anonymisées ou sur des jeux de données synthétiques qui conservent la structure mais masquent les informations sensibles. Lorsque l’on utilise une API externe, on doit vérifier les conditions de traitement des données du prestataire : certains offrent des options de non‑rétention ou de suppression immédiate après réponse. En interne, un environnement isolé (par exemple, une machine virtuelle sans connexion internet) permet d’exécuter des modèles ouverts comme Mistral sans sortir les données du périmètre de l’entreprise.

Que faire si les résultats de mes expérimentations sont contradictoires avec mes intuitions ?

Dans ce cas, il convient de revenir aux sources : vérifier la qualité et la représentativité des données utilisées, s’assurer que le modèle n’a pas été biaisé par un réglage inadéquat (par exemple, une température trop élevée entraînant des réponses aléatoires), et éventuellement faire appel à un collègue possédant une expertise métier pour interpréter les écarts. La contradiction n’est pas forcément un échec ; elle peut révéler un hypothèse implicite qui mérite d’être examinée avant d’engager un projet plus large.