Comment débuter un projet d'intelligence artificielle en entreprise sans se tromper

La semaine dernière, un dirigeant m'appelle. Il a lu partout qu'il fallait "y aller". Il a demandé un devis à un intégrateur : 90 000 € pour un assistant qui répond aux clients. Il me demande si c'est raisonnable. Je lui réponds qu'il pose la mauvaise question.

La bonne question, celle qui décide si votre premier projet d'intelligence artificielle en entreprise aboutira ou finira aux oubliettes, n'est pas "combien ça coûte". C'est : "quel problème précis, mesurable, et ennuyeux, vais-je régler ?". Dans mon expérience, les projets qui échouent ne sont presque jamais des échecs techniques. Ce sont des échecs de cadrage.

Je vais vous montrer comment je m'y prends aujourd'hui. Pas la théorie en six étapes qu'on trouve partout. La vraie mécanique, avec les chiffres que j'ai vus sur mes propres projets, les erreurs que j'ai commises, et les moments où j'ai perdu de l'argent.

Comment débuter un projet d'intelligence artificielle en entreprise sans se tromper de combat

En 2024, j'ai accompagné une entreprise de logistique. Le patron voulait "un chatbot IA". Trois mois plus tard, personne ne l'utilisait. Coût réel : 22 000 €. Le problème n'était pas la technologie. Le problème, c'est que personne n'avait de question à poser au chatbot. Les clients appelaient, comme avant.

J'ai retenu une leçon simple. Une IA ne crée pas un besoin. Elle amplifie un besoin existant.

Comment choisir son premier cas d'usage

Je travaille avec une grille à deux axes, que j'ai bricolée après plusieurs projets ratés. En abscisse : l'impact business (temps gagné, argent récupéré, erreurs évitées). En ordonnée : la faisabilité (la donnée existe-t-elle ? le processus est-il stable ?).

Le piège, c'est de viser le quadrant "fort impact, faible faisabilité". Tout le monde veut le faire. C'est là qu'on s'enlise. Le bon premier projet vit dans "impact moyen, faisabilité élevée". Un quick win. Pas le projet dont vous rêvez.

Concrètement, je cherche :

• Une tâche répétitive que vos équipes font chaque semaine, à la main.
• Un processus déjà documenté, avec des données propres et accessibles.
• Un endroit où une erreur coûte cher (relances, saisie, tri de mails).
• Un cas où vous pouvez mesurer le résultat en moins de deux mois — sinon vous pilotez à l'aveugle.

Sur un projet récent, on a commencé par le tri automatique des factures fournisseurs. Aucun glamour. Mais l'équipe comptable y passait six heures par semaine. On a réduit à quarante minutes. Personne n'a écrit d'article de presse là-dessus. Tout le monde était content.

L'erreur que je vois le plus souvent

Vouloir commencer par le cas d'usage le plus visible. Le service client, la vente, le marketing. Ce sont les plus médiatisés, donc les plus demandés. Ce sont aussi les plus durs : données dispersées, processus mouvants, attentes floues.

Je préfère les coulisses. La finance, les opérations, la logistique interne. Moins de prestige, beaucoup moins de friction. Et franchement, c'est là que j'ai vu les gains les plus rapides.

Combien ça coûte et combien de temps ça prend vraiment

Ici, je vais vous donner des chiffres. Pas des fourchettes de cabinet. Des ordres de grandeur que j'ai constatés sur mes projets, en PME et ETI.

Type de premier projet	Budget indicatif	Délai réel	Risque principal
Automatisation d'une tâche répétitive (tri, extraction, résumé)	8 000 – 15 000 €	4 à 8 semaines	Données non structurées
Assistant interne sur vos documents (base de connaissances)	12 000 – 25 000 €	6 à 10 semaines	Qualité de la documentation
Prédiction simple (détection d'anomalies, scoring)	15 000 – 40 000 €	8 à 14 semaines	Historique de données insuffisant
"Chatbot" grand public	20 000 – 90 000 €	3 à 6 mois	Adoption utilisateur, périmètre flou

Ces montants incluent la préparation des données, le développement, et un peu d'accompagnement au changement. Ce qui coûte cher, ce n'est presque jamais le modèle. C'est la plomberie autour.

Avouons-le : la ligne "chatbot grand public" est celle que tout le monde me demande. C'est aussi celle que je déconseille le plus souvent comme premier projet. Le ratio risque/bénéfice y est le plus mauvais.

Le coût caché : la donnée

Sur un de mes premiers projets, j'avais sous-estimé la préparation des données. J'avais annoncé trois semaines. Il en a fallu neuf. Le client a failli arrêter. Depuis, je compte systématiquement la moitié du temps total sur la donnée seule.

La question à se poser avant de démarrer : où sont vos données, sous quel format, et qui peut y accéder sans passer par trois validations ? Si la réponse est floue, votre projet démarrera mal.

Les bonnes pratiques qui font la différence entre un test et un vrai résultat

Un POC qui marche dans un coin, c'est bien. Un POC qui change la vie d'une équipe, c'est mieux. La différence tient à trois ou quatre habitudes que j'ai fini par adopter par la force des choses.

Définir la métrique de succès avant de commencer

Je refuse de lancer un projet sans une phrase du type : "Si à la fin, on est passé de X à Y, c'est gagné." Une seule métrique. Pas trois. Pas un tableau de bord.

Exemples que j'ai utilisés :

1. Le temps moyen de traitement d'une facture (passé de 9 minutes à 4, dans un cas).
2. Le nombre d'erreurs de saisie par mois.
3. Le délai de première réponse à un client.
4. Le nombre de documents à relire manuellement — je vise une baisse franche, sinon à quoi bon ?

Cette phrase unique sert à deux choses. Elle vous protège des dérives de périmètre. Et elle vous donne un argument béton au moment de demander le budget suivant.

Poser un cadre minimal sur les données

Je ne vais pas vous écrire un traité sur la conformité. Mais il y a des garde-fous à poser d'entrée, sinon c'est le mur assuré.

• Savoir où vivent les données que vous allez utiliser.
• Vérifier qui a le droit d'y accéder — chez vous, pas dans l'absolu.
• Décider ce qui ne sortira jamais de vos murs (données clients, données RH).
• Écrire noir sur blanc ce que vous ferez si le modèle se trompe. Un humain garde la main au début. Toujours.

Le dernier point est celui qu'on oublie le plus. Sur un projet de tri de candidatures, on avait prévu une relecture humaine systématique. Sage décision : le modèle classait correctement, mais il pénalisait certains profils atypiques. Sans relecture, on aurait pris une décision absurde. La correction a pris deux jours. Le rattrapage aurait pris des mois.

À quoi s'attendre vraiment côté équipes

Quand j'ai commencé, je pensais que la résistance viendrait des directions. En pratique, elle vient surtout des personnes dont le travail change. Et c'est normal.

J'ai vu une équipe saboter un outil parfaitement fonctionnel pendant deux semaines. Pas par malveillance. Parce que personne ne leur avait expliqué pourquoi. Une fois la réunion faite — une seule, d'une heure — le taux d'usage est passé de 20 % à 70 % en dix jours.

Les bénéfices que je constate le plus souvent :

• Du temps rendu sur des tâches sans valeur ajoutée. C'est le gain le plus immédiat et le moins contestable.
• Moins d'erreurs sur les tâches répétitives — entre autres parce que l'attention humaine fatigue, pas le modèle.
• Une meilleure réactivité sur des volumes qui, à la main, saturaient les équipes.
• Et, plus subtil : de la donnée exploitable là où il n'y en avait pas. Vos tableaux de bord s'améliorent tout seuls.

Inversement, j'ai vu un cas où l'outil a fait baisser la charge de travail d'une équipe… sans que la direction le remarque. Résultat : on a rajouté des dossiers pour "occuper". Mauvaise décision. Si vous gagnez du temps, décidez à l'avance à quoi il servira. Sinon il sera mangé.

Faut-il commencer par une formation ?

Ça dépend du niveau de départ. Si personne dans l'équipe n'a jamais manipulé un outil d'IA générative, une demi-journée de mise à niveau change tout. Ne cherchez pas un cursus de trente heures. Visez l'usage concret : quels outils, quelles limites, quelles règles internes.

Dans tous les cas, la formation la plus utile est celle qui vient après le premier projet qui marche. Vos équipes apprennent mieux sur un cas réel que sur des slides.

Le piège qui tue la moitié des projets

Le POC sans suite. Vous connaissez la chanson : un test qui marche, une démo réussie devant le comité, et puis plus rien. Pas de budget pour la suite. Pas de responsable. L'outil meurt dans un coin.

J'ai vécu ce scénario deux fois. Les deux fois, la cause était la même : on n'avait pas décidé avant de démarrer ce qu'on ferait si le test était concluant. Personne n'avait écrit : "si la métrique atteint Y, on déploie en janvier, avec telle équipe, sur tel budget."

Alors voici ce que je fais maintenant systématiquement. Avant de lancer le premier test, je fais signer au commanditaire trois choses : la métrique de succès, la date de décision, et le nom de la personne qui portera le projet ensuite. C'est peu. Mais ça change tout.

Un premier projet d'IA en entreprise n'est pas un pari technologique. C'est un pari organisationnel. La technique suit, presque toujours. Le cadrage, la décision, et la personne qui porte — c'est là que se joue le résultat.

Si vous ne devez retenir qu'une chose, retenez celle-ci : choisissez un problème ennuyeux, mesurez une seule chose, et engagez-vous sur la suite avant même de commencer. Le reste n'est que du travail.