Retour au projet
Étude de cas

Drawzy AI - Étude de cas du hackathon MobAI

Étude de cas sur la partie IA de Drawzy, couvrant la reconnaissance de dessins, le score de type apprentissage par renforcement, l'intégration mobile et l'architecture des dépôts de l'équipe.

Vue d'ensemble

Drawzy est un prototype de jeu de dessin réalisé en équipe lors du hackathon MobAI de l'ENSIA. Cette étude de cas se concentre sur la contribution IA : un backend FastAPI pour la prédiction de dessins mobiles et le score des manches.

Problème

L'IA devait s'insérer dans une boucle de jeu rapide : export du dessin mobile, normalisation côté backend et réponse simple que l'interface de jeu puisse utiliser pendant la démo.

Contexte

L'organisation publique compte trois dépôts : drawzy-ai pour FastAPI, drawzy-mobile pour Flutter/Firebase et drawzy-landing pour Next.js. La formulation du rôle reste centrée sur la partie IA/backend.

Mon rôle

Contributeur IA concentré sur le service de modèles, le prétraitement des dessins, l'API de prédiction et le score de type apprentissage par renforcement. Les surfaces mobile et d'accueil sont créditées comme un travail d'équipe.

Objectifs

  • Fournir un backend d'IA que l'écran de dessin mobile puisse appeler pendant une partie
  • Décoder la sortie du canevas mobile envoyée sous forme de données d'image en base64
  • Prétraiter les dessins en niveaux de gris de 28x28, la forme attendue par le classifieur
  • Renvoyer des prédictions de dessins à partir d'un modèle CNN entraîné
  • Exposer une route de score pilotée par des signaux de manche de type temps et similarité
  • Garder une architecture assez simple pour une démo de hackathon et une relecture ultérieure du portfolio

Décisions techniques

  • Utiliser FastAPI et Pydantic pour une petite API de service de modèles, explicite
  • Séparer les routes de prédiction et de score par des routeurs pour que le service d'IA ait des responsabilités claires
  • Convertir les dessins en niveaux de gris, les recadrer sur la zone dessinée détectée, conserver les proportions et les remplir à 28x28 avant l'inférence
  • Utiliser un modèle CNN TensorFlow/Keras pour la classification de dessins sur un sous-ensemble de type Quick, Draw
  • Utiliser un environnement Gymnasium et un modèle PPO Stable-Baselines3 pour un mécanisme de score prototype
  • Faire encoder par l'application Flutter la sortie du canevas en octets PNG et l'envoyer en JSON à l'endpoint de prédiction
  • Garder les sessions mobiles adossées à Firebase, l'état de chat/jeu et la page d'accueil hors de la frontière du backend d'IA

Architecture

L'application Flutter envoie à FastAPI des images de canevas en base64. Le backend décode, prétraite en un tenseur de niveaux de gris 28x28, appelle le CNN et renvoie la classe devinée. Pour le score, il construit une observation de 61 valeurs et appelle le modèle PPO.

Schéma d'architecture

Mermaid
flowchart LR
  Player["Joueur mobile"] --> Mobile["Application Flutter Drawzy"]
  Mobile --> Canvas["Canevas de dessin et modes de jeu"]
  Canvas --> GuessRoute["Route FastAPI de prédiction de dessin"]
  GuessRoute --> ImagePrep["Décodage base64, recadrage, redimensionnement, remplissage"]
  ImagePrep --> GuessModel["Modèle CNN de devinette de dessins"]
  GuessModel --> Predictions["Classe prédite et cinq meilleures hypothèses"]
  Mobile --> ScoreRoute["Route FastAPI de score"]
  ScoreRoute --> Observation["Chronologie de similarité et score précédent"]
  Observation --> ScoreModel["Modèle de score PPO"]
  ScoreModel --> RoundScore["Score de la manche"]
  Mobile --> Firebase["Services applicatifs Firebase"]
  Landing["Page d'accueil Next.js"] --> Mobile

Captures d'écran de l'étude de cas

4 vues
Courbes d'entraînement du modèle de devinette, issues du backend d'IA, pour le classifieur de dessins.
Écran d'accueil et de marque de l'application Flutter, qui donne au backend d'IA un contexte produit visible.
Écran de choix du mode pour les parties de dessin hors ligne, en ligne et multijoueur.
Visuel d'intégration issu du dépôt mobile, qui montre le prototype comme une expérience d'application complète.

Fonctionnalités clés

  • Route de prédiction de dessins sous le routeur de prédiction FastAPI
  • Flux de requête base64 vers image de Flutter à Python
  • Logique de recadrage de la zone dessinée et de remplissage qui garde les dessins centrés pour l'inférence
  • Chemin de prédiction de la classe principale à partir du modèle CNN
  • Route de score de type apprentissage par renforcement utilisant le temps et une séquence de similarité de 60 pas
  • Canevas de dessin Flutter avec une action de prédiction visible et un état de réponse
  • Travail multijoueur/sessions adossé à Firebase dans le dépôt mobile
  • Dépôt de page d'accueil qui présente l'application de hackathon comme un produit partageable

Défis

  • Rendre fiable l'entrée du modèle quand les dessins des utilisateurs sont clairsemés, décentrés ou vides
  • Garder compréhensible le contrat d'API mobile/backend sous la pression du temps d'un hackathon
  • Transformer des artefacts de ML en endpoints que le reste de l'équipe pouvait appeler
  • Présenter le projet publiquement sans surestimer la maturité du prototype
  • Expliquer assez clairement l'organisation en trois dépôts aux visiteurs du portfolio

Résultats

  • Une étude de cas publique issue de l'organisation du hackathon MobAI
  • Des visuels réels extraits des dépôts mobile et IA au lieu de captures d'écran de substitution
  • Le backend d'IA documenté de l'export du canevas mobile jusqu'à l'inférence et au score FastAPI
  • Le rôle précisé comme une contribution IA/backend, avec une explication de la façon dont le prototype de l'équipe s'assemble

Ce que j'ai appris

  • Le travail d'IA en hackathon est plus facile à évaluer quand le modèle a une vraie surface produit qui l'appelle
  • Le prétraitement peut compter autant que le modèle quand les dessins viennent de vrais utilisateurs
  • Les démos courtes ont besoin de petits contrats d'API que les coéquipiers frontend/mobile peuvent utiliser rapidement
  • Les études de cas de portfolio doivent séparer la contribution personnelle des surfaces gérées par l'équipe