Module 7
Construire votre solution IA
Objectifs d’apprentissage
- Livrer un prototype no-code au périmètre clair
- Documenter les tests et les limites
- Comparer sa réalisation à un corrigé argumenté
1. Relier les six modules. Le projet mobilise votre carnet de prompts, le choix d’outils, les calculs contrôlés, le cahier des charges, le workflow et la compréhension du public. La séance de 90 minutes sert à cadrer et démarrer ; la réalisation et les retours peuvent s’étaler sur deux semaines. Le cas de référence corrigé est BIZNIS AI. Vous pouvez adapter la méthode à un autre projet Build for Haiti, en explicitant vos critères.
2. Définir le contrat du prototype. Pour un commerçant fictif, permettre la saisie de ventes en HTG, le calcul du total et une synthèse courte contrôlée. Exclure comptes clients, paiements, bénéfice sans coûts et prévisions. Les données sont pédagogiques. Indiquez si vous livrez une application testée, une maquette ou une simulation ; ces preuves ne démontrent pas le même niveau de réalisation.
3. Construire par petites étapes. Commencez par les champs et les validations, puis la liste et les calculs. Ajoutez la synthèse seulement quand les données sont fiables. Si vous n’avez pas de service IA relié, utilisez un exemple de réponse clairement marqué comme simulé. Aucun outil payant n’est requis pour rédiger le dossier ; une version papier est possible, mais elle ne prouve pas un fonctionnement logiciel.
4. Faire une recette documentée. Préparez les entrées et les sorties attendues avant les tests. Vérifiez cas normal, entrée invalide, liste vide, limite de connexion et lecture sur téléphone. Pour chaque essai, notez résultat réel, date, défaut et correction. Ne remplacez pas un test par une capture d’écran jolie. Le quiz vérifie les connaissances ; il ne valide pas à lui seul votre projet.
5. Recueillir et traiter les retours. Avec leur accord, demandez à trois personnes d’exécuter la tâche et observez les difficultés. Ne collectez ni données réelles de clients ni informations sensibles. Si ces personnes ne sont pas disponibles, signalez que la validation utilisateur reste à faire. Corrigez un problème concret et montrez ce qui a changé. Un avis positif isolé n’est pas une preuve d’impact économique.
6. Livrer de façon honnête. Le dossier présente problème, périmètre, fonctionnement, données fictives, prompts, tests, limites et amélioration prioritaire. Le corrigé ci-dessous est un exemple de référence et une grille d’autoévaluation, pas une correction automatique de votre travail. La soumission existante permet de joindre description et lien ; dans cette démonstration, les retours du formateur restent limités au même navigateur.
Une synthèse finale correcte
« Sur les trois jours fictifs, les ventes totalisent 7 900 HTG pour 30 unités. Le mardi présente le chiffre d’affaires le plus élevé : 3 000 HTG. Les coûts ne sont pas renseignés ; le bénéfice et les ventes futures ne peuvent pas être déterminés. » Ce texte reprend uniquement les agrégats vérifiés. Il n’attribue aucune cause à la variation et ne propose pas de crédit ou d’investissement.
Exercice pratique
Pendant la séance de 90 minutes : consacrez 15 minutes au problème et au périmètre, 20 au cahier des charges et aux écrans, 30 à une première réalisation ou maquette, 15 aux tests et 10 au bilan. Continuez ensuite la réalisation et les retours sur deux semaines si nécessaire. Livrez BIZNIS AI avec les données fictives du module 3, une synthèse contrôlée, un tableau de tests et une note de limites. Comparez votre dossier au corrigé, puis soumettez la description et le lien de votre prototype ou de votre documentation.
Corrigé proposé de l’exercice
Avant d’ouvrir le corrigé détaillé, vérifiez que votre dossier distingue ce qui fonctionne, ce qui est simulé et ce qui n’a pas été testé. Une autoévaluation n’est pas une note attribuée par le formateur.
Le total de référence est 7 900 HTG. La synthèse ne doit annoncer ni bénéfice ni prévision. Si votre prototype ne respecte pas ces deux points, corrigez d’abord les données et le texte avant d’améliorer son apparence.
Projet de fin de parcours · BIZNIS AI
Le dossier à réaliser
BIZNIS AI — Un récapitulatif de ventes pour un petit commerçant fictif. Objectif : saisir des ventes pédagogiques, calculer les recettes et préparer une synthèse vérifiée, sans programmation obligatoire ni données de clients.
Livrables attendus
- Une fiche problème, public et périmètre, avec hypothèses signalées
- Un prototype ou une maquette explicitement identifiée, avec lien ou documentation
- Le jeu fictif de trois ventes et les calculs vérifiés
- Le prompt de synthèse et son résultat relu
- Un tableau de cinq tests minimum : attendu, observé, défaut et correction
- Les retours utilisateurs consentis, ou la mention qu’ils restent à recueillir
- Une note sur confidentialité, stockage, connexion, coûts éventuels et prochaine amélioration
Étapes de réalisation
- Cadrer le besoin avec la fiche du module 6 et retenir seulement la saisie, les totaux et la synthèse
- Créer date, produit, quantité et prix unitaire en HTG, avec validations explicites
- Ajouter les trois ventes fictives et contrôler les montants et le total
- Produire la synthèse depuis les agrégats, puis la faire relire avant diffusion
- Exécuter les tests, recueillir les retours disponibles et corriger un défaut documenté
- Comparer le dossier à la grille, puis joindre description et lien à la soumission BIZNIS AI
Corrigé de référence du projet
Exemple pédagogique et résultats attendus ; aucune note automatique n’est attribuée à votre réalisation.
1. Problème et périmètre
Dossier de référence fictif : un commerçant souhaite éviter les erreurs dans un récapitulatif. La première version enregistre des ventes et prépare un brouillon relu. Elle ne gère ni paiement, ni conseil financier, ni stock complet. Le besoin demeure une hypothèse tant qu’aucun utilisateur ne l’a confirmé.
2. Données et calculs
Lundi : 10 × 250 = 2 500 HTG ; mardi : 12 × 250 = 3 000 HTG ; mercredi : 8 × 300 = 2 400 HTG. Total : 7 900 HTG, 30 unités. Quantité : entier strictement positif ; prix : nombre strictement positif ; produit et date : obligatoires. Les montants sont calculés, pas saisis comme réponses de l’IA. Une entrée invalide n’est pas enregistrée silencieusement.
3. Écrans attendus
Écran de saisie : champs nommés avec unités, validation compréhensible et confirmation d’ajout. Écran de récapitulatif : liste des ventes, montants, total et brouillon de synthèse. État vide : 0 HTG, aucune vente enregistrée. Les informations essentielles restent lisibles sur téléphone. Si les données sont locales, cette limite est annoncée ; si l’IA est absente, la réponse est étiquetée simulation.
4. Prompt et réponse de référence
Prompt : « À partir de ces agrégats fictifs uniquement : 7 900 HTG, 30 unités, recettes lundi 2 500, mardi 3 000, mercredi 2 400, rédige trois phrases. Ne calcule pas de bénéfice, ne prédis pas les ventes et n’invente aucune cause. Signale les coûts inconnus. » Réponse acceptable : la synthèse donnée dans l’exemple de cette leçon. Toute valeur nouvelle doit être vérifiée ou retirée.
5. Recette de référence — résultats attendus, pas tests exécutés
Test A : ajouter 10 unités à 250 → 2 500 HTG. Test B : ajouter les trois ventes → total 7 900 HTG. Test C : quantité −1 → refus explicite. Test D : liste vide → 0 HTG sans synthèse inventée. Test E : couper la connexion → indiquer les actions indisponibles, ne pas annoncer une sauvegarde distante réussie. Test F : ouvrir sur téléphone → saisir et lire les résultats sans contenu masqué. Votre dossier doit ajouter les résultats réellement observés ; cette liste ne prouve aucune exécution.
6. Exemple de retour et amélioration — simulation
Retour fictif : une personne confond prix unitaire et montant. Correction proposée : renommer le champ « Prix par unité (HTG) » et afficher le calcul avant ajout. Ce retour sert d’exemple et ne doit pas être présenté comme un entretien réel. Votre propre dossier conserve le défaut observé, la correction et le résultat du nouvel essai.
7. Limites et suite
La maquette ne prouve pas la sauvegarde ni la sécurité multiutilisateur. Le prototype ne prouve pas un gain de revenu. Les données réelles nécessiteraient des protections et accès appropriés. Priorité suivante possible : améliorer le traitement d’une erreur de saisie ou la reprise après coupure, avant d’ajouter des fonctions sensibles. Une automatisation éventuelle garde la validation humaine et le suivi des doublons du module 5.
Grille d’autoévaluation · 20 points
Besoin et périmètre
4 pointsPublic et tâche explicites ; hypothèses distinguées des observations ; exclusions justifiées.
Données et exactitude
5 pointsMontants 2 500, 3 000, 2 400 HTG et total 7 900 HTG vérifiés ; validations et unités définies.
Usage responsable de l’IA
4 pointsPrompt traçable, synthèse sans invention, données fictives et validation humaine.
Réalisation et tests
4 pointsAu moins cinq scénarios documentés ; preuves et résultats observés pour les essais réellement exécutés ; simulations et limites signalées.
Documentation et recul
3 pointsLivrables accessibles, retours réels ou absence signalée, limites et amélioration prioritaire expliquées.
Quiz de connaissances
1. Le quiz final valide-t-il automatiquement le prototype ?
2. Quelle synthèse est acceptable ?
3. Un résultat attendu dans le corrigé est-il une preuve de votre test ?
4. Comment présenter un retour utilisateur inventé pour l’exemple ?
5. Quel dossier rend la réalisation évaluable ?
À retenir
- Livrez un résultat vérifiable, pas seulement une belle interface.
- Le corrigé est une référence, pas une note automatique.
- Documentez les limites et les essais réellement effectués.