Trois pistes, par ordre de préférence du professeur : une super app pour un métier, un utilitaire où l'IA fait la différence, un jeu ou une simulation. Chaque fiche est pensée pour O1 et O2 : une sortie du modèle structurée, enregistrée et réutilisée, un domaine métier de quatre entités au moins, un coût par usage qui tient dans 1 € de crédit avec un petit modèle. Les exigences O3 à O7 restent à concevoir. Prenez une fiche telle quelle, tordez-la, ou remplacez-la par la vôtre.
- Public et problème : qui, et quelles corvées on lui enlève.
- Les outils (super apps) : ce que l'application fait pour ce métier, trois à cinq tâches, chacune en « X → Y → Z ».
- La phrase O1 : l'outil central, celui qui fait tout le trajet « l'utilisateur fournit X, le modèle produit Y, l'application en fait Z ».
- Ce que le modèle ne fait pas : la part du produit qui est du code classique, c'est elle qui vous distingue d'un wrapper.
- Entités : le squelette de votre base, partagé par tous les outils.
- Coût d'un usage : la taille de ce qui entre et sort du modèle, prompt système compris. Faible = moins de deux mille jetons par appel. Moyen = deux à dix mille. Élevé = au-delà (textes longs, images, conversations). Un modèle qui « raisonne » facture aussi ses jetons de réflexion. Une recherche web par le modèle coûte moins d'un centime en plus.
- Piège : ce qui fait échouer ce projet quand on ne l'a pas vu venir.
- Supplémentaires : des pistes pour le degré de maîtrise.
Piste 1 — Une super app pour un métier#
Choisissez un métier que vous connaissez : le vôtre, celui d'un proche, celui de votre employeur. Listez ses corvées de la semaine. Pour chacune, demandez-vous ce qu'un modèle peut faire (rédiger, extraire, classer, proposer, comparer, chercher) et ce que votre application doit faire autour (stocker, relier, valider, planifier, envoyer après accord). Vous obtenez un couteau suisse pour ce métier.
La règle qui sépare une super app de cinq wrappers côte à côte : ses outils partagent les mêmes données. Le courrier trié nourrit le carnet de contacts, le compte rendu crée des tâches, le devis devient une facture. Et l'un des outils au moins fait tout le trajet X → Y → Z (O1).
Public et problème. Un enseignant passe ses soirées à écrire des énoncés, des corrigés, des quiz, des chapitres et des courriels, souvent à partir du même cours.
Les outils. Un chapitre collé → un lot d'exercices avec corrigé, variantes et difficulté → banque d'exercices publiable. Une liste d'objectifs → un plan de chapitre et un premier jet → le professeur l'édite, section par section, et le publie. Une copie collée et la grille → un diagnostic par critère et une note proposée → le professeur valide ou corrige, l'application garde la trace et produit le retour à l'étudiant. Une question d'étudiant → un brouillon de réponse ancré sur le cours → envoyé après relecture.
La phrase O1. Le professeur colle un chapitre. Le modèle produit un lot d'exercices structurés (énoncé, corrigé, difficulté, objectif visé). L'application les range dans la banque du cours, génère des variantes à la demande et compose des séries d'exercices ou des quiz à partir de la banque.
Ce que le modèle ne fait pas. La banque, les versions, la publication, les séries, les grilles, les notes finales, l'envoi des retours.
Entités. Cours, chapitres, exercices, variantes, grilles, copies, corrections, étudiants.
Coût d'un usage. Élevé par chapitre collé, moyen par copie corrigée, faible pour un courriel.
Piège. La correction entièrement automatique : le professeur valide chaque note, l'application le lui impose. Les copies contiennent des noms : anonymisez avant l'envoi au modèle.
Supplémentaires. Import d'un PDF, export vers un format de quiz, statistiques par objectif, mode « élève » pour tester la série.
Public et problème. La secrétaire d'une asbl, d'un cabinet, d'une PME ou d'une école jongle entre le courrier, les réunions, l'agenda et les courriers types, avec dix fenêtres ouvertes.
Les outils. Un message collé ou transféré → classé, champs extraits, brouillon de réponse d'après les modèles de la maison → file, affectation, validation avant envoi. Des notes de réunion → compte rendu structuré, décisions, actions (quoi, qui, pour quand) → rattachées aux contacts, rappelées à la réunion suivante. Une demande de rendez-vous en langage libre → contraintes extraites → créneau proposé dans l'agenda. Une consigne (« lettre de rappel pour les cotisations impayées ») → courrier d'après le modèle et les données → PDF, envoi après accord.
La phrase O1. La secrétaire colle un message. Le modèle le classe, extrait les champs utiles et rédige un brouillon de réponse. L'application crée la demande dans la bonne file, l'affecte, et n'envoie rien tant que le brouillon n'est pas validé.
Ce que le modèle ne fait pas. Les contacts, les files, les délais, l'agenda, les modèles de courrier, le suivi des actions, l'envoi.
Entités. Organisations, contacts, messages, demandes, réunions, actions, rendez-vous, modèles de courrier.
Coût d'un usage. Faible par message, moyen par réunion.
Piège. Un outil envoyé sans validation humaine : chaque envoi passe par un bouton « j'ai relu ». Les messages contiennent des données personnelles : n'envoyez au modèle que ce qu'il faut.
Supplémentaires. Réception par vraie boîte e-mail, lecture d'un courrier scanné, deux langues, tableau de bord « qui attend depuis trop longtemps ».
Public et problème. Une ressourcerie, une brocante en ligne ou un magasin de seconde main reçoit des objets à la pelle. Personne n'a le temps d'écrire des fiches, de chercher le prix du marché ni de répondre aux mêmes questions.
Les outils. Trois mots et une photo → fiche structurée (titre, description, catégorie, état, mots-clés) → catalogue. L'objet identifié → le modèle cherche sur le web les prix pratiqués et renvoie une fourchette avec ses sources → l'application la confronte au barème interne et propose un prix. Une question d'acheteur → réponse ancrée sur la fiche → envoyée après validation. Les invendus du mois → suggestion de baisse de prix → appliquée en un clic.
La phrase O1. Le bénévole saisit trois mots et une photo. Le modèle produit la fiche et, par une recherche web, une fourchette de prix sourcée. L'application calcule le prix de vente avec le barème, publie la fiche, suit le stock et les ventes.
Ce que le modèle ne fait pas. Le catalogue, le barème, le calcul du prix, le stock, les ventes, les statistiques, l'envoi des réponses.
Entités. Boutiques, articles, catégories, photos, comparaisons de prix, ventes, questions.
Coût d'un usage. Moyen avec la photo, plus la recherche web (moins d'un centime).
Piège. Croire une fourchette sans ses sources : affichez-les, et gardez le barème comme garde-fou. Commencez sans la photo.
Supplémentaires. Étiquette à imprimer, panier et réservation, texte pour les réseaux sociaux, alerte quand un objet recherché arrive.
Public et problème. Chercher un stage ou un premier emploi, c'est trente offres, quinze mails, cinq relances, un CV jamais à jour et des lettres qui se ressemblent.
Les outils. Un profil et des critères → le modèle cherche les offres sur le web et les qualifie (entreprise, poste, technologies, missions) → fiches dans un kanban, score calculé par rapport au profil. Une offre choisie → CV adapté (ordre, mots-clés) et lettre de motivation → versions enregistrées, éditables. Une candidature prête → courriel rédigé → envoyé après validation, relances planifiées. Les refus → analyse des écarts → compétences à travailler.
La phrase O1. Le candidat enregistre son profil et ses critères. Le modèle trouve et qualifie des offres. L'application calcule un score d'adéquation, range les offres dans le kanban (repérée, envoyée, entretien, réponse) et planifie les relances.
Ce que le modèle ne fait pas. Le profil, le score, le kanban, les versions de CV, les relances, l'envoi, les statistiques.
Entités. Profils, CV (versions), offres, entreprises, candidatures, lettres, courriels, relances.
Coût d'un usage. Moyen : la recherche puis une qualification par offre, le CV en contexte pour chaque lettre.
Piège. Le courriel qui part tout seul : la validation est obligatoire. Le CV contient des données personnelles : dites-le dans la politique de confidentialité, et n'envoyez pas ce qui ne sert pas.
Supplémentaires. Lecture d'une page d'offre dont l'utilisateur donne l'adresse, CV exporté en PDF, entretien d'entraînement (fiche 9), partage anonymisé des entreprises qui recrutent avec la promotion.
Public et problème. Un électricien, un peintre ou un menuisier indépendant passe ses soirées sur les devis, les factures, les relances et les photos de chantier à trier.
Les outils. Une description du besoin (texte ou vocal transcrit) → devis structuré (postes, quantités, unités) → prix calculés avec le barème, PDF, envoi après accord. Des photos et une note en fin de journée → compte rendu de chantier → rattaché au chantier, visible par le client. Un devis accepté → facture et échéancier. Une facture en retard → courrier de rappel d'après le modèle → envoyé après accord.
La phrase O1. L'artisan décrit le travail demandé. Le modèle produit la liste structurée des postes et quantités. L'application applique le barème, compose le devis, le fait signer et le transforme en facture.
Ce que le modèle ne fait pas. Le barème, les prix, les clients, les chantiers, les factures, les échéances, l'envoi.
Entités. Clients, chantiers, devis, lignes de devis, interventions, factures, relances.
Coût d'un usage. Faible par devis, moyen avec les photos.
Piège. Laisser le modèle inventer un prix : il propose des postes, le barème fixe les prix. Mentions obligatoires d'une facture : à vérifier au chapitre du deuxième cours.
Supplémentaires. Dictée vocale, signature en ligne, planning des chantiers, export comptable.
D'autres métiers à imaginer : le libraire, l'agent immobilier, le photographe, le responsable RH d'une PME, le gestionnaire d'une copropriété, l'agent de voyage, le journaliste local, le responsable d'un club sportif, le coordinateur de stages d'une école. Même méthode : les corvées, puis ce que le modèle fait et ce que votre code fait autour.
Piste 2 — Un utilitaire où l'IA fait la différence#
Deux familles où un modèle change vraiment la donne : encoder (une photo, un texte libre ou un document deviennent des données structurées sans formulaire), et trancher pour un groupe (des contraintes de chacun, une proposition que tout le monde peut discuter).
Public et problème. Quatre colocataires, un budget serré, des goûts différents, et chaque soir la même question.
La phrase O1. Les membres déclarent leurs contraintes (budget, aversions, ingrédients exclus) et ce qu'il reste dans le frigo. Le modèle propose une semaine de menus sous forme structurée (recettes, ingrédients, quantités). L'application en déduit la liste de courses, répartit qui cuisine quand, et apprend des notes données aux plats.
Ce que le modèle ne fait pas. Le planning, la liste de courses agrégée, les notes, l'historique « plus jamais ce gratin », le partage des coûts.
Entités. Foyers, membres, préférences, recettes, ingrédients, menus, listes de courses, notes.
Coût d'un usage. Moyen : une génération par semaine par foyer.
Piège. Laisser le modèle inventer des quantités absurdes ou glisser un ingrédient exclu : votre code vérifie la structure, les bornes et les ingrédients de chaque recette avant de l'enregistrer. Ne collectez pas de données de santé (allergies, régimes médicaux).
Supplémentaires. Photo du frigo (une image compte pour des centaines à quelques milliers de jetons), prix estimés, export vers une application de courses, recettes favorites partagées entre foyers.
Public et problème. Une colocation, un club, un voyage entre amis : des tickets de caisse dans toutes les poches, un tableur que personne ne tient, et la question « qui doit quoi à qui ».
La phrase O1. Un membre photographie un ticket ou écrit « j'ai payé 42 € de courses pour tout le monde sauf Lina ». Le modèle produit une dépense structurée (montant, date, catégorie, payeur, bénéficiaires). L'application l'enregistre, calcule les soldes, propose les remboursements qui minimisent les virements et les marque faits.
Ce que le modèle ne fait pas. Les groupes, les membres, les soldes, l'algorithme de remboursement, l'historique, les statistiques par catégorie.
Entités. Groupes, membres, dépenses, parts, remboursements, catégories.
Coût d'un usage. Faible en texte, moyen avec la photo du ticket.
Piège. Un montant mal lu sur un ticket : l'application montre ce qu'elle a compris et demande confirmation avant d'enregistrer.
Supplémentaires. Devises, export CSV, rappel des dettes, budget par catégorie, reconnaissance des tickets récurrents.
Public et problème. Organiser un week-end à huit, c'est trois semaines de messages de groupe et personne qui décide.
La phrase O1. Chaque participant donne ses dates, son budget, ses envies et ses contraintes. Le modèle produit deux ou trois programmes structurés (lieu, activités, répartition du budget, ce qui plaît à qui). L'application les soumet au vote, enregistre le programme retenu, en fait un planning partagé et une liste de tâches réparties.
Ce que le modèle ne fait pas. Les participants, le vote, le planning, les tâches, le budget suivi, l'historique des week-ends.
Entités. Groupes, participants, contraintes, propositions, votes, programmes, tâches.
Coût d'un usage. Moyen : une génération par vague de contraintes.
Piège. Le modèle qui invente un lieu ou un prix : donnez-lui des lieux de votre base ou une recherche web, et faites valider chaque chiffre.
Supplémentaires. Recherche web des lieux, météo, export calendrier, comptes du groupe (fiche 7).
Piste 3 — Un jeu ou une simulation#
Public et problème. Les fictions interactives classiques répètent les mêmes phrases. Les chats « jeu de rôle » oublient tout et laissent le joueur tricher.
La phrase O1. Le joueur écrit une action en langage libre. Le modèle produit la narration et une liste structurée d'effets sur le monde (objet pris, indice découvert, personnage interrogé, lieu déverrouillé). L'application applique ces effets à l'état du jeu stocké en base, refuse les effets impossibles d'après les règles, et sert au modèle, au tour suivant, l'état exact du monde.
Ce que le modèle ne fait pas. Les règles, l'inventaire, la carte, les indices, les conditions de victoire, les sauvegardes, le classement des enquêteurs.
Entités. Scénarios, lieux, objets, personnages, indices, parties, tours, inventaires.
Coût d'un usage. Moyen par tour : l'état du monde entre à chaque fois, gardez-le compact.
Piège. Faire porter les règles par le prompt : le joueur trouvera la faille. Les règles sont dans votre code. Un seul scénario de cinq lieux suffit, l'éditeur de scénarios vient après.
Supplémentaires. Streaming de la narration, illustrations générées des lieux, mode deux joueurs, éditeur de scénarios pour l'administrateur.
Votre propre idée#
Elle est bienvenue, à une condition : la fiche. Remplissez les six premières rubriques du gabarit (public et problème, les outils pour une super app, phrase O1, ce que le modèle ne fait pas, entités, coût) et faites-la valider au premier cours ou sur Teams avant la deuxième séance. Si vous n'arrivez pas à écrire le Z de la phrase O1, c'est un wrapper.
À éviter#
- Le wrapper : une boîte de dialogue devant un modèle, même avec un joli prompt système. Un traducteur, un résumeur, un reformulateur, un générateur de posts ou de newsletters. Rien n'est enregistré, rien n'est relié, l'AA 2 est impossible à évaluer. Cinq wrappers côte à côte ne font pas une super app.
- La santé, le droit et la finance : pré-diagnostic, conseil juridique, conseil d'investissement, même avec un avertissement. Le risque légal est au-dessus de ce qu'un projet de sept semaines peut porter.
- L'aspiration de sites en masse : copier des sites d'emploi, d'avis ou d'actualité. C'est fragile, souvent interdit par leurs conditions, et votre produit casse à la première mise à jour. Une recherche web à la demande par le modèle, ou la lecture d'une page dont l'utilisateur donne l'adresse, c'est autre chose.
- Les clones d'outils de développement : générateur de tests, documentation automatique d'un dépôt. Vous les utiliserez en théorie, vous ne les construirez pas en sept semaines.
- Le modèle qui agit seul : envoyer un courriel, supprimer, payer, publier sans validation humaine ni vérification par votre code. Préparer l'envoi, oui. Envoyer sans le bouton « j'ai relu », non.