« On va faire un truc avec l’IA » n’est pas un cas d’usage IA : c’est une intention. Chaque année, des étudiants, des chercheurs et des porteurs de projet marocains partent de la technologie plutôt que du problème, et livrent une démonstration impressionnante qui ne résout rien pour personne. Voici comment choisir un cas d’usage IA qui tient, avant d’écrire la première ligne de code.
Le piège du projet IA « par la technologie »
Le schéma se répète : quelqu’un découvre une capacité — classification, génération de texte, vision par ordinateur — et cherche ensuite un problème où l’appliquer. Le résultat est souvent une solution en quête de problème : techniquement correcte, mais que personne n’a demandée et que personne n’utilisera après la soutenance ou la démo.
L’ordre inverse fonctionne mieux. On part d’un problème réel, documenté, ressenti par des personnes identifiables. On vérifie ensuite si l’IA est la bonne réponse — ce qui n’est pas toujours le cas. Une règle simple, un formulaire mieux conçu ou un processus manuel réorganisé résolvent parfois le même problème plus vite et à moindre risque. Ce n’est qu’une fois le problème posé que la question des usages concrets de l’IA générative devient pertinente — pas avant.
Le coût d’un mauvais choix n’est pas seulement technique. Un cas d’usage mal cadré consomme des semaines de développement, épuise la motivation d’une équipe et, dans un contexte académique, occupe un temps de recherche qui aurait pu servir une question mieux posée. Se tromper de cas d’usage coûte presque toujours plus cher que le temps passé à le choisir correctement.
Quatre critères pour repérer un cas d’usage utile
Avant de valider une idée, passez-la au filtre de ces quatre critères. Si l’un d’eux reste sans réponse claire, ce n’est pas encore un cas d’usage : c’est une hypothèse à creuser.
| Critère | Question à trancher | Signal d’alerte |
|---|---|---|
| Problème documenté | Qui souffre de ce problème, et depuis quand ? | Personne ne peut citer un cas concret vécu récemment |
| Données disponibles | Ces données existent-elles déjà, en qualité suffisante ? | « On les collectera plus tard » |
| Valeur mesurable | Comment saura-t-on que le projet fonctionne, en une métrique ? | Aucune métrique définie avant de commencer |
| Supervision possible | Qui vérifie les résultats dans la durée, une fois le projet lancé ? | Personne n’est prévu pour ce rôle |
Le critère le plus souvent négligé est le dernier. Un modèle qui fonctionne le jour de la démo n’est pas la même chose qu’un système supervisé pendant des mois, avec quelqu’un capable de détecter une dérive ou une erreur silencieuse.
Comparer plusieurs candidats plutôt que trancher d’instinct
Un seul cas d’usage évalué isolément donne rarement une bonne décision : tout paraît prometteur quand on n’a rien à comparer. Listez trois à cinq idées candidates, puis notez chacune sur deux axes simples : l’effort estimé pour arriver à un premier test crédible (données à réunir, complexité de la logique, dépendances externes) et la valeur attendue si le test manuel confirme l’intuition (nombre de personnes concernées, fréquence du problème, gain réel par occurrence).
Les candidats à retenir en premier sont ceux qui combinent un effort faible et une valeur claire : ce sont eux qui permettent de tester une hypothèse rapidement, sans engager des mois de travail sur un pari non vérifié. Un cas d’usage à fort effort et à valeur incertaine peut rester intéressant sur le papier, mais il doit attendre d’avoir des preuves plus solides avant de mobiliser une équipe.
Cet exercice de comparaison a un autre mérite : il oblige à formuler chaque idée en une phrase précise — qui, quel problème, quelle fréquence — plutôt qu’en une direction vague du type « appliquer l’IA à l’agriculture » ou « un assistant pour les étudiants ». Une idée qui résiste mal à cet exercice de reformulation n’est probablement pas encore assez mûre pour être développée.
Où chercher un vrai cas d’usage au Maroc
Le meilleur point de départ n’est pas une liste d’outils, mais un secteur où un problème concret revient souvent : santé, agriculture, énergie, éducation, services financiers. Chaque secteur a ses contraintes propres — accès aux données, réglementation, saisonnalité — qui orientent fortement ce qui est réalisable.
L’écosystème d’accompagnement marocain donne une indication utile sur cette diversité : l’EIC a, à ce jour, accompagné 175 projets, tous secteurs confondus. Cette dispersion sectorielle n’est pas un hasard : un cas d’usage IA solide se trouve rarement en copiant celui du voisin, mais en creusant un problème spécifique à un terrain que vous connaissez déjà, comme porteur de projet, étudiant ou chercheur.
Le contexte marocain de l’IA — programmes de formation, infrastructures, initiatives sectorielles, détaillé dans notre panorama Maroc IA 2030 — crée aussi des signaux de demande qu’il vaut la peine de suivre plutôt que de deviner depuis un bureau.
Pour un étudiant ou un chercheur, le terrain le plus fiable reste souvent celui déjà exploré dans un travail académique, un stage ou un projet de fin d’études : les données y sont plus accessibles, le problème est déjà partiellement documenté, et un encadrant ou un partenaire de terrain peut confirmer si la douleur identifiée est réelle. Partir d’un terrain connu réduit fortement le risque de construire un cas d’usage qui semble pertinent sur le papier mais ne rencontre aucun utilisateur réel.
Tester avant de coder
Le meilleur test d’un cas d’usage IA ne demande pas de modèle du tout. Traitez dix cas à la main, en suivant exactement la logique que le système automatiserait plus tard. Cet exercice, parfois appelé test « magicien d’Oz », révèle en quelques heures ce qu’aucune spécification technique ne montre : la variabilité réelle des cas, les exceptions fréquentes, et si le problème mérite vraiment d’être automatisé.
Cette étape rejoint une logique plus large de validation avant construction, déjà détaillée dans notre méthode pour tester un besoin marché avant de développer. Le principe est identique : parler à dix personnes concernées coûte une journée ; développer un système inutile en coûte plusieurs mois.
Checklist avant de lancer un projet IA
Avant de mobiliser du temps de développement, vérifiez chaque point :
- Le problème est décrit par une personne concrète, pas par une tendance générale
- Trois personnes différentes confirment vivre ce problème régulièrement
- Les données nécessaires existent déjà, ou leur collecte est planifiée et réaliste
- Une métrique de succès est définie avant le premier prototype
- Le test manuel (sans modèle) a été fait sur au moins dix cas
- Une personne est identifiée pour superviser les résultats après le lancement
- Une alternative plus simple qu’un modèle IA a été envisagée et écartée pour une raison précise
Si un seul point reste sans réponse, ce n’est pas un blocage définitif — mais c’est un signal qu’il reste du travail avant de coder.
Conclusion
Un bon cas d’usage IA ne se reconnaît pas à la sophistication du modèle, mais à la clarté du problème qu’il résout, à la disponibilité des données et à la présence de quelqu’un pour en superviser les résultats dans la durée. Pour un étudiant, un chercheur ou un porteur de projet au Maroc, cette discipline de sélection en amont fait souvent plus la différence qu’un mois de développement supplémentaire.
