Réponse en bref
Choisissez le projet d’après le problème, non d’après la technologie. Formulez l’objectif en une phrase sans nommer de modèle, vérifiez que vous avez le droit d’utiliser les données, mesurez d’abord une référence simple, resserrez le périmètre pour qu’il entre dans les semaines disponibles et décidez à l’avance de la façon dont le résultat sera testé. Terminez par un court texte indiquant à quoi sert le système, où il échoue et ce que vous n’avez pas vérifié.
Le projet est le moment où le cours devient votre décision
Les leçons et les exercices d’un cours d’IA appliquée sont choisis pour vous. Le projet, non. C’est la seule partie où vous décidez quoi construire, avec quelles données et comment savoir si cela a fonctionné, et c’est en général le travail que vous montrerez ensuite à un employeur ou à un client.
La plupart des projets décevants échouent avant la première ligne de code. L’apprenant choisit une technique qui impressionne, cherche ensuite un problème auquel la rattacher, puis découvre en cinquième semaine que les données n’existent pas. La page consacrée aux projets du cours d’apprentissage profond CS230 de Stanford relève que les projets d’application, où vous choisissez un problème qui vous intéresse et cherchez comment lui appliquer des algorithmes d’apprentissage, sont de loin les plus courants.
Cinq tests distinguent un projet pour un cours d’IA viable d’un simple souhait : un vrai problème, des données que vous avez le droit d’utiliser, une référence à battre, un périmètre qui tient dans les semaines disponibles et une évaluation que vous savez expliquer. Un sixième vient à la fin : un exposé honnête des limites.
Formuler l’objectif dans une phrase qui ne nomme aucun modèle
Le cours de Google « Introduction to Machine Learning Problem Framing », une courte formation en ligne d’environ 45 minutes selon sa propre estimation, s’ouvre sur une consigne qui paraît trop simple pour compter : formulez votre objectif sans vocabulaire d’apprentissage automatique, comme la réponse à la question « Qu’est-ce que je cherche à accomplir ? ». Ses exemples tiennent chacun en une ligne : détecter le spam, calculer un temps de trajet, repérer les transactions frauduleuses.
Faites de même avec votre idée. « Affiner un modèle de langage sur des tickets de support » est une méthode. « Répartir les messages de support entrants dans cinq files pour que les urgents soient traités en premier » est un objectif : il dit qui en profite et ce qui change. Si vous n’arrivez pas à écrire une phrase du second type, vous avez un outil et pas encore de projet.
Le même cours ajoute un test qui écarte bien des idées séduisantes : prédire quelque chose n’a aucune valeur si la prédiction ne peut pas devenir une action qui aide les utilisateurs. Demandez-vous ce qu’une personne ferait différemment le lundi matin avec la sortie de votre système. Un score soigné qui ne change le travail de personne est un exercice, et un exercice fait un moins bon projet qu’un petit outil utile.
Des données que vous pouvez utiliser et décrire par écrit
L’autorisation passe avant la qualité. Utilisez des données que vous avez créées vous-même, un jeu public dont la licence couvre votre usage, ou des documents d’un employeur avec un accord écrit et sans informations personnelles. Lisez la licence et les conditions sur la page du jeu de données lui-même ; « c’était sur Internet » n’est pas une licence. Si les données décrivent des personnes identifiables, demandez d’abord au cours ou à l’organisation comment elles doivent être traitées.
Jugez ensuite si elles peuvent porter le projet. Le cours de Google énumère ce que doivent être les données d’un modèle prédictif : abondantes, cohérentes et fiables, dignes de confiance, disponibles au moment de la prédiction, correctes et représentatives du monde réel. Un apprenant réunit rarement les six qualités. La voie honnête consiste à noter celles qui sont faibles et à réduire d’autant ce que l’on affirme.
Comptez aussi le temps. Les consignes de CS230 à Stanford préviennent que, lorsque les données demandent un prétraitement important ou que vous comptez les collecter vous-même, ce n’est qu’une partie du travail attendu, mais qu’elle prend souvent un temps considérable. Une règle pratique : si vous ne parvenez pas à ouvrir un échantillon exploitable des données la première semaine, changez d’idée, pas de calendrier.
Une référence à battre avant toute sophistication
Une référence de base (baseline) est la chose la plus simple capable de faire le travail : une règle, une liste de mots-clés, le processus manuel actuel ou un modèle prêt à l’emploi utilisé avec une consigne d’une ligne. Le cours de Google appelle la solution sans apprentissage automatique le point de comparaison qui permet de décider si l’apprentissage automatique convient au problème, et suggère de le résoudre à la main avec une heuristique si une telle solution n’existe pas encore.
C’est la référence qui donne un sens à votre chiffre final. Une illustration avec des chiffres inventés : un classifieur qui a raison 90 fois sur 100 paraît solide jusqu’à ce que l’on remarque que choisir toujours la catégorie la plus fréquente donne 88 bonnes réponses. L’écart de deux points est le résultat, et il est modeste. Sans la référence, vous auriez annoncé 90 et rien appris.
Construisez-la tôt. Le même cours conseille de commencer simplement, parce que l’essentiel du travail porte sur les données, et observe que les modèles simples font une bonne référence même s’ils ne sont jamais mis en service. CS230 demande, au point d’étape, un code qui fonctionne avec un modèle de référence. Quelles que soient les exigences de votre cours, une référence opérationnelle dans le premier tiers du calendrier signifie que vous avez déjà quelque chose de complet à rendre.
Réduire le périmètre jusqu’à ce qu’il tienne dans le calendrier
Comptez les semaines dont vous disposez vraiment, puis soustrayez. La dernière revient au compte rendu, l’avant-dernière à l’évaluation et à l’analyse des erreurs, et une au moins sera perdue à cause du travail, d’une maladie ou d’un ordinateur en panne. Ce qui reste est le temps des données et de la construction, et c’est en général bien moins que ne le supposait le premier plan.
Resserrez la tâche au lieu de diluer le travail. Une langue, un type de document, une catégorie de clients, trois classes plutôt que douze. Écrivez la plus petite version qui resterait un projet complet, avec des données, une référence, un test et une conclusion, et considérez tout le reste comme facultatif. Un projet étroit et terminé apprend davantage qu’un projet large et inachevé.
Méfiez-vous des idées qui dépendent de ce que vous ne maîtrisez pas : un jeu de données que quelqu’un a promis, un accès soumis à validation, des milliers d’exemples à annoter à la main. Les consignes de Stanford pour le point d’étape cherchent la preuve que l’équipe a testé toute hypothèse susceptible de l’empêcher de mener le projet à terme. Testez les vôtres dès la première semaine, quand changer de direction coûte encore peu.
Une évaluation que vous pourriez expliquer à un collègue
Décidez comment vous jugerez le résultat avant de le construire. Mettez de côté une partie des exemples comme jeu de test et ne la regardez pas pendant que vous réglez le système ; un score mesuré sur des exemples qui ont servi à vos réglages ne dit rien des nouveaux. Choisissez une mesure principale qui découle de la phrase d’objectif, et soyez prêt à dire simplement ce que représente un point de cette mesure.
Le cours de Google sépare deux choses que les apprenants confondent souvent. Les métriques du modèle, comme l’exactitude (accuracy), la précision et le rappel, décrivent le modèle. Les métriques de réussite décrivent ce qui vous importe, par exemple le fait que les gens prennent plus souvent la bonne décision. Un projet qui rapporte les premières et discute les secondes montre que son auteur a compris le problème, pas seulement la bibliothèque.
Un texte généré demande un autre type de test. Le cours note qu’il peut falloir un jeu de test pour comparer la sortie d’un modèle génératif à des valeurs connues, par exemple vérifier que les résumés ressemblent à ceux rédigés par des humains ou que des personnes les jugent bons. En pratique, cela veut dire une courte grille de trois ou quatre critères, un ensemble fixe d’entrées et, si vous pouvez l’organiser, une deuxième personne pour noter.
Les limites vont dans le compte rendu, pas en note de bas de page
La recherche fournit un canevas tout prêt. L’article « Model Cards for Model Reporting », de Margaret Mitchell et de ses coauteurs, propose qu’un modèle entraîné soit accompagné d’un court document révélant le contexte dans lequel il est destiné à être utilisé et la manière dont ses performances ont été évaluées. Parmi les rubriques suggérées figurent l’usage prévu, les cas d’usage hors périmètre, les données d’évaluation, ainsi que les réserves et recommandations.
Un projet pour un cours d’IA peut reprendre l’idée sur une page. Dites à quoi sert le système et qui devrait l’utiliser. Dites à quoi il ne doit pas servir. Décrivez les données et ce qui leur manque. Donnez le résultat à côté de la référence. Montrez ensuite trois ou quatre échecs réels et dites ce qu’ils ont en commun. Des exemples d’échec convainquent davantage qu’une phrase admettant qu’il en existe.
Les apprenants craignent souvent que l’énumération des faiblesses ne joue contre eux. Pensez à la façon dont un correcteur ou un employeur lit la page : un résultat n’inspire confiance que lorsque ses frontières sont visibles. « Fonctionne sur des factures en anglais de deux fournisseurs ; non testé sur l’écriture manuscrite » est un constat. Le silence sur la même lacune est une erreur qui attend d’être découverte par quelqu’un d’autre.
Confronter l’idée à autre chose que la technique
Le document de l’UNESCO « AI competency framework for students » (référentiel de compétences en IA pour les élèves), publié en 2024 à l’intention des programmes scolaires, décrit 12 compétences réparties en quatre dimensions : un état d’esprit centré sur l’humain, l’éthique de l’IA, les techniques et applications de l’IA et la conception de systèmes d’IA. Il les ordonne selon trois niveaux de progression : comprendre, appliquer et créer. Il n’a pas été écrit pour des cours d’adultes, mais il fait un bon miroir.
Placez votre idée devant lui. Un projet qui se contente de régler un modèle exerce une seule dimension. Celui qui demande en plus qui est touché par une sortie erronée, à qui appartiennent les données et comment les éléments s’assemblent en un système qui fonctionne touche les quatre. Et un projet dans lequel vous construisez, testez et améliorez quelque chose de personnel se situe au niveau « créer », celui que vise un cours appliqué.
Lisez le règlement de votre propre cours avant de vous engager, car les règles varient d’un cours à l’autre. La page de CS230 indique, au moment où ces lignes sont écrites, que se borner à donner des consignes à un grand modèle de langage sans entraînement supplémentaire ne constitue pas un projet valable pour ce cours ; un autre cours peut accepter exactement cela, et le cours de Google observe que, dans la plupart des cas, on personnalise un modèle génératif préentraîné au lieu d’entraîner le sien. Choisissez ensuite entre vos idées candidates à l’aide des cinq tests, et préférez celle dont vous pouvez ouvrir les données aujourd’hui.
Checklist pratique
- Écrivez l’objectif en une seule phrase, sans nommer de modèle ni de technique, et dites qui agirait à partir du résultat.
- Obtenez par écrit l’autorisation d’utiliser les données et notez leur origine, leur licence, leur date et leurs lacunes connues.
- Mesurez une référence simple sur des exemples mis de côté avant de construire quoi que ce soit de plus complexe.
- Planifiez à rebours depuis l’échéance et définissez la plus petite version qui compte encore comme un projet complet.
- Terminez par une page sur l’usage prévu, les usages hors périmètre, le résultat à côté de la référence et de vrais exemples d’échec.
Questions et réponses
Comment choisir entre deux idées de projet pour un cours d’IA ?
Notez chaque idée avec les mêmes cinq questions : le problème est-il réel, avez-vous le droit d’utiliser les données, pouvez-vous bâtir une référence cette semaine, la plus petite version complète tient-elle dans le calendrier, et savez-vous expliquer comment vous la testerez. L’idée dont les données sont déjà entre vos mains mérite en général de l’emporter, même si l’autre paraît plus excitante. L’enthousiasme ne survit pas à un mois d’attente pour obtenir un accès.
Un projet fondé sur un modèle de langage prêt à l’emploi est-il trop simple ?
Cela dépend du règlement de votre cours. Certains, comme CS230 à Stanford, exigent un travail d’entraînement et précisent que donner des consignes à un modèle ne suffit pas. Là où le règlement l’autorise, la profondeur vient d’ailleurs : un objectif précis, un jeu de test assemblé avec soin, une comparaison avec une référence plus simple et une analyse des échecs. Ce sont les parties que l’on saute le plus facilement, et celles qui montrent du discernement.
Qu’appelle-t-on une référence de base dans un projet d’apprentissage automatique ?
Toute méthode simple qui accomplit la même tâche et peut être notée sur les mêmes exemples de test : une règle écrite à la main, une correspondance de mots-clés, la prédiction systématique de la classe la plus fréquente, le processus manuel existant ou un modèle standard avec une consigne minimale. Son rôle est la comparaison. Présentez son score à côté du vôtre, mesuré de la même façon, pour que le lecteur voie ce que votre travail a ajouté.
Puis-je utiliser les données de mon employeur pour un projet de cours ?
Seulement avec l’autorisation écrite d’une personne habilitée à la donner et, normalement, après suppression des informations personnelles et confidentielles. Vérifiez aussi ce que le cours fait des travaux rendus, car les rapports et le code peuvent être lus par l’équipe pédagogique ou partagés avec d’autres apprenants. Si l’autorisation tarde ou reste incertaine, choisissez un jeu de données public doté d’une licence claire. Il s’agit d’indications générales et non d’un conseil juridique ; ce sont les règles de votre organisation qui décident.
Quelle taille doit avoir le jeu de données d’un projet de cours ?
Il n’existe pas de chiffre universel. Le cours de Google sur le cadrage des problèmes dit que davantage d’exemples pertinents donnent un meilleur modèle, et cite parmi ses autres exigences des données correctes et représentatives. Pour un projet court, un test utilisable consiste à se demander si les exemples mis de côté contiennent tous les types de cas que vous prétendez traiter et si vous pouvez vérifier vous-même leurs étiquettes. Si l’une des réponses est non, réduisez ce que vous affirmez avant de collecter davantage.