L’IA dans une PME : par où commencer

Comment reconnaître un bon premier cas d’usage ?

Cinq critères, tous vérifiables sans expertise technique.

La fréquence : la tâche revient chaque semaine, pas deux fois par an. Le temps passé : quelqu’un sait combien d’heures elle coûte. La règle : il existe une manière de faire, écrite ou dictable en dix minutes. La tolérance à l’erreur : une réponse fausse se repère, se corrige, et n’engage ni la sécurité ni la signature de l’entreprise. La donnée : ce qu’il faut pour travailler existe déjà, sous forme exploitable.

Un cas qui coche les cinq est rarement spectaculaire. Demandes entrantes, comptes rendus, préparation de devis, recherche dans les documents internes : c’est là que ça commence.

Un critère manquant n’est pas éliminatoire. Trois le sont.

Que faut-il vérifier avant de lancer ?

Quatre questions, avant la première dépense. Qui décide ? Un projet sans propriétaire nommé s’arrête au premier arbitrage. Il faut quelqu’un qui tranche, et un utilisateur réel qui dira si c’est utile.

Quelles données sont concernées ? Listez-les. Données personnelles, données clients, informations couvertes par un contrat : le régime diffère, et cela se règle avant.

Qui a le droit d’y accéder — et où ont-elles le droit d’aller ? L’outil ne doit ouvrir à personne ce que ses accès actuels lui refusent, ni faire sortir de l’entreprise ce qui doit y rester.

Que se passe-t-il si le résultat est faux ? Qui le voit, qui le corrige, ce que cela coûte. Si personne ne sait répondre, le cas d’usage est mal choisi.

Quelle séquence suivre, concrètement ?

Quatre temps. Cadrer : une page — la tâche visée, qui la fait aujourd’hui, ce qui compte comme un bon résultat, ce qui est hors périmètre. Si cette page ne s’écrit pas, le projet n’est pas mûr.

Essayer petit. Une version limitée, sur un vrai bout de travail, avec deux ou trois utilisateurs volontaires. Pas une démonstration : un essai en conditions réelles.

Évaluer sur des cas réels. Reprenez des dossiers déjà traités, dont vous connaissez la bonne réponse, et comparez. C’est fastidieux ; c’est la seule preuve qui vaille.

Décider. Étendre, ajuster, ou arrêter. Le droit d’arrêter fait partie de la méthode : un essai qui conclut « non » a fait son travail. C’est tout l’intérêt de commencer petit.

Quels pièges reviennent le plus souvent ?

Quatre, et ils se ressemblent d’une entreprise à l’autre. Commencer par le cas le plus visible plutôt que le plus simple : le sujet dont tout le monde parle est souvent le plus enchevêtré — plusieurs services, données éclatées, forte exposition. Gardez-le pour le deuxième projet.

Confondre démonstration et mise en service. Une maquette convaincante ne dit rien du travail restant : droits d’accès, cas particuliers, reprise d’erreur, formation.

Ne prévoir personne pour l’entretien. Un outil vit : les documents changent, les règles évoluent, les modèles aussi. Sans responsable identifié, il se dégrade en silence.

Croire qu’il faut « entraîner une IA sur nos données ». Le plus souvent, non : le système consulte vos documents au moment de la question, sans apprendre dessus. Plus simple, plus rapide, plus facile à corriger.

Quel cadre légal faut-il connaître ?

Deux textes, et ils ne demandent pas la même chose.

Le RGPD, dès que des données personnelles sont en jeu — clients, salariés, candidats. Base légale, information des personnes, durée de conservation : les règles habituelles s’appliquent, et la CNIL publie des fiches pratiques dédiées à l’IA. Une analyse d’impact devient obligatoire dans certains cas, notamment en présence de profilage ou de décision automatisée.

Le règlement européen sur l’IA, en application depuis le 2 août 2026, mais par étapes : un règlement de juillet 2026 a repoussé les obligations « haut risque » au 2 décembre 2027, et au 2 août 2028 pour l’IA intégrée à des produits déjà réglementés. Deux points arrivent plus tôt. La maîtrise de l’IA : depuis février 2025, vous devez prendre des mesures pour que vos équipes se forment aux outils qu’elles utilisent — une obligation de moyens, pas un niveau à garantir. L’information des personnes : un système conçu pour dialoguer doit signaler qu’on s’adresse à une IA, sauf lorsque c’est évident au vu du contexte ; l’obligation pèse sur celui qui conçoit l’outil.

Aucun de ces textes n’interdit de commencer. Ils imposent de savoir ce que vous faites.

Faut-il un prestataire, et que lui demander ?

Un premier essai sur des outils du marché se mène souvent en interne, à condition de dégager du temps à quelqu’un. Dès qu’il faut connecter vos systèmes, gérer des droits d’accès ou tenir l’outil dans la durée, un renfort extérieur se justifie.

Ce qu’on demande à un prestataire tient en peu de choses : qu’il dise où vont vos données et sous quel régime ; qu’il documente ce qu’il construit, pour qu’un autre puisse reprendre ; qu’il accepte un critère de réussite écrit à l’avance ; qu’il vous dise quand un cas ne vaut pas la peine.

Regardez aussi ce qui existe déjà : la Direction générale des entreprises porte un plan national de diffusion de l’IA, avec des diagnostics et des accompagnements cofinancés, ouverts aux PME et ETI sous conditions.

Quand vaut-il mieux ne pas commencer maintenant ?

Il y a des moments où la réponse honnête est « pas encore ». Quand personne n’a de temps : un projet d’IA consomme des heures d’un métier, pas seulement d’un informaticien. Sans ces heures, l’outil se construit sur des suppositions.

Quand le processus n’est pas stabilisé. Si la manière de faire change tous les mois, ou si personne ne sait dire ce qu’est un bon résultat, vous obtiendrez du désordre plus rapide.

Quand le savoir n’est écrit nulle part. Ce qui n’existe que dans la tête de deux personnes ne s’outille pas ; il s’écrit d’abord.

Quand le vrai problème est ailleurs. Beaucoup de sujets présentés comme des sujets d’IA se règlent par un champ de formulaire, une règle plus claire ou une réunion supprimée. Nous le disons quand c’est le cas.