17 mai 2026 Mis à jour le 18 mai 2026 Développement

Développer une app mobile avec l’IA : retour d’expérience

Une soirée libre, un projet qui traînait depuis douze ans, et Claude comme unique développeur. L’occasion parfaite de faire un peu de R&D.

Quelques heures plus tard, j’avais une application web fonctionnelle, utilisable sur smartphones Android & iOS. Voici ce que cette expérience m’a appris sur les possibilités et les limites du développement assisté par IA (a.k.a « vibe coding » ou « programmation intuitive »).

Le projet de l’assistant vestimentaire « As de pique »

L’idée initiale de l’application

Le concept est simple : analyser les couleurs d’une tenue à partir d’une photo prise au smartphone, pour en valider l’association et suggérer des alternatives compatibles. Une sorte d’assistant qui aide à valider l’harmonie de couleurs.

Le tout dans une interface mobile intuitive, idéalement une PWA (Progressive Web App) pour être installée sur l’écran d’accueil comme une vraie application et être utilisée en mode hors ligne.

Pourquoi avoir attendu toutes ces années ?

Parce que je ne suis pas développeur et que l’émergence des IA conversationnelles capables de générer du code est un joker aussi puissant que récent.

J’avais envie de tester sur un cas concret, sans aucun enjeu commercial, juste pour voir jusqu’où il est possible d’aller. Un projet personnel expérimental, parfait pour échouer, recommencer et tester des approches différentes.

Une PWA complète en une soirée

Résultat après quelques heures de travail : une PWA entièrement fonctionnelle composée d’un fichier HTML autonome d’environ 200 Ko contenant 35 fonctions JavaScript. Ni framework complexe ni serveur backend, juste une application qui fonctionne 100 % côté client.

Principales fonctionnalités

  • Caméra intégrée avec démarrage automatique
  • Points repositionnables pour sélectionner manuellement les zones de couleur à analyser
  • Zoom et navigation tactile pour placer les points avec précision
  • Analyse multi-critères (harmonie générale, niveau de saturation, équilibre chaud/froid)
  • Suggestions contextuelles avec des vignettes de couleurs recommandées
  • Détection des motifs incompatibles (par exemple, le mélange de rayures et de carreaux)
  • Possibilité d’installer l’application sur l’écran d’accueil du smartphone
  • Compatibilité avec le mode hors ligne
  • Historique des photos et du score associé à chaque association de couleurs
  • Partage du résultat

Le processus de travail

J’ai travaillé exclusivement avec Claude, en utilisant l’application desktop quand j’étais sur mon ordinateur, et l’application mobile quand je rédigeais mes prompts dehors en promenant mon chien. La fonctionnalité « Cowork » de Claude m’a permis de donner accès à mon système de fichiers local : pas besoin de copier-coller du code, Claude pouvait directement créer et modifier les fichiers.

Au bout d’environ 20 itérations, la version 4 me semble répondre au cahier des charges. 

Cerise sur le gâteau, un simple accès à mon terminal avec la fonctionnalité « Code » de Claude m’a permis de déployer automatiquement vers un hébergement gratuit de Netlify.

My tailor is rich, donc il m’offre les fonctionnalités sur-mesure

Sélection manuelle des couleurs

Au départ, je voulais que l’application détecte automatiquement les couleurs dominantes de la tenue. Claude a proposé plusieurs algorithmes : analyse des zones centrales de l’image, filtres progressifs de saturation, suppression de l’arrière-plan… Aucun ne donnait de résultats satisfaisants. Les couleurs extraites étaient souvent grises, désaturées, ou totalement hors sujet.

J’ai imaginé donc imaginé une approche manuelle : l’utilisateur place lui-même des points sur les zones de couleur qui l’intéressent. L’application extrait alors la couleur exacte sous chaque point. Plus simple, plus fiable, et finalement plus pertinent.

L’aperçu couleur en temps réel

Une fois le système de points manuels en place, un besoin UX est apparu : comment visualiser la couleur sélectionnée avant de relâcher le doigt ?

J’ai demandé à Claude d’ajouter un aperçu pendant le déplacement d’un point. De cette manière une pastille s’affiche au-dessus du doigt (pour ne pas être masquée par ce même doigt) avec la couleur extraite, son nom et son code hexadécimal mis à jour en temps réel pendant le drag.

Cette fonctionnalité a été intégrée sans difficulté. Claude a compris l’intention UX et l’a traduite en code fonctionnel. Tout simplement.

Deux accrocs difficilement raccommodables

Limite #1 : Dépendance aux compétences de l’IA

Je fais confiance aveuglément aux choix techniques proposés par Claude. Pour un projet personnel, c’est acceptable. Pour un projet client avec des enjeux de performance, de sécurité ou de maintenabilité, cette dépendance sera problématique à court ou moyen terme. 

Il faut garder en tête qu’on délègue l’écriture du code, ainsi que les décisions d’architecture. Sans expertise technique pour challenger ces choix, on peut se retrouver avec une solution fonctionnelle mais non optimale. En découle alors autant de questions sans réponse :

  • Pourrait-on faire plus léger, plus rapide ?
  • Existe-t-il des failles de sécurité que je ne vois pas ?
  • Les bonnes pratiques actuelles sont-elles respectées ?
  • Le code est-il maintenable par un autre développeur ?

Limite #2 : Gestion des tokens

Les échanges longs consomment beaucoup de tokens (fragments de mots). Pour développer cette PWA en une soirée, j’ai consommé ~97 000 tokens dans la conversation avec Claude. Pour donner un ordre de grandeur : cela représente 41% du volume de « La Communauté de l’Anneau ».

4 heures de travail pour 97 000 tokens vs. 17 années d’immenses souffrances pour ce bon vieux Tolkien avec sa trilogie à 607 000 tokens.

Une telle volumétrie pose au moins trois problèmes :

  1. La consommation énergétique
    Chaque requête à une IA générative consomme de l’énergie. À l’échelle d’un projet, 97 000 tokens représentent une empreinte carbone non négligeable. La question de l’impact environnemental du développement assisté par IA est une réalité.
  2. La consommation de crédits
    Sur des projets plus longs ou complexes, le coût en tokens peut devenir significatif, surtout si on doit revenir plusieurs fois sur le contexte pour des ajustements.
  3. La perte de contexte
    Si je reprends le projet après une interruption de plusieurs jours, Claude ne se souvient pas automatiquement de toutes les décisions prises. J’ai dû créer une documentation externe (changelog et document de passation) pour pouvoir recréer le contexte si besoin.

Dans quels cas cette approche est bien ajustée ?

  • Prototypage rapide
    Valider une idée avant d’investir dans un développement professionnel. Créer un POC (proof of concept) fonctionnel pour tester une hypothèse, vérifier un besoin utilisateur, ou convaincre des parties prenantes.
  • Projet personnel et apprentissage
    Concrétiser des idées sans budget développement. Comprendre la logique de développement web en voyant comment les fonctionnalités sont implémentées. Apprendre en faisant, même sans savoir coder.

Et dans quels cas cette approche taille trop court ?

  • Confidentialité et protection
    Applications manipulant des données sensibles (santé, finances, données personnelles). Tout ce qui nécessite des garanties de sécurité renforcées et des audits de code.
  • Application évolutive et durable
    Architectures avancées, besoins de performance élevés ou projets nécessitant une montée en charge progressive. L’évolutivité du code produit par IA n’est pas garantie, et si un autre développeur doit intervenir plus tard, il peut avoir du mal à comprendre certaines parties ou certaines décisions d’architecture.

Les conditions de la réussite

Pour optimiser les chances de succès avec cette approche, quatre conditions me semblent essentielles :

  1. Avoir une vision claire du résultat attendu 
    Plus l’expression de besoins est précise, meilleurs seront les résultats. L’IA n’est pas magique, elle traduit ce qu’on lui demande.
  2. Accepter les limites et ne pas viser la perfection technique
    Un code fonctionnel n’est pas forcément un code optimal. Si le projet fonctionne et répond au besoin, c’est déjà une réussite.
  3. Documenter les choix importants
    Pour faciliter les reprises, les évolutions, ou le passage de relais à un développeur. Sans documentation, on se retrouve vite perdu.
  4. Savoir quand passer le relais à une équipe de professionnels
    Sur un projet professionnel, à enjeu commercial et/ou technique, l’intervention humaine reste indispensable.

En une soirée, j’ai formalisé une idée vieille de douze ans. Ce rendu n’a pas l’étoffre d’un vrai projet client, il s’agit d’un simple POC sans prétention.

 

As de pique

Portrait de Guiillaume
Rédigé par Guillaume Thibord