Pour maitriser l'IA, l’expérience prime sur la technique

Nous avons récemment partagé ce qu’implique le fait de devenir “AI-native”. En quelques mots : les outils IA nous permettent enfin d’agir directement sur des produits finis, et plus seulement sur des “spécifications” que sont des maquettes ou des prototypes.

Cette situation nous pousse à redéfinir notre rôle : nous devons désormais nous positionner du côté des résultats et de l’impact, pas seulement des moyens.

Et ce n’est pas qu’une posture théorique. Depuis des mois, nous mettons ces technologies à l’épreuve dans les coulisses de l’agence pour éprouver leurs limites.

Voici aujourd’hui 4 convictions que nous avons tirées de cette nouvelle façon de travailler, illustrées par 4 produits réels shippés par l’équipe.

1. L’IA permet de créer la traction, le Designer crée la rétention

Le Vibe Coding et les composants prêts à l’emploi sont incroyablement efficaces pour sortir un MVP, résoudre un problème technique et prouver un concept (la traction). Mais face à des milliers d’apps générées par l’IA qui inondent les stores, une UI standardisée, même très propre, ne suffit pas. C’est là que le rôle du designer devient vital : aller au-delà de l’existant pour créer de la préférence et fidéliser l’utilisateur (la rétention).

🛠️ L’exemple de Nestor

Par Jules Bassoleil, Co-fondateur @ Source.paris

• Le projet : Une app iOS pour planifier les menus familiaux et générer automatiquement des listes de courses triées par rayons.

• Stack : Cursor (Claude Opus 4.6), Xcode, Firebase, Supadata, Superwall

• Durée du projet : Une semaine pour la première beta

• Statut : publiée sur l’App Store

Je n’avais jamais écrit une ligne de SwiftUI. Quelques semaines plus tard, Nestor était sur l’App Store : sync temps réel, import depuis n’importe quelle source, images générées par IA. Sur le plan technique, l’IA a tout rendu possible.
Mais ce qu’elle ne peut pas décider, c’est l’essentiel. Que l’app soit monochrome, noir-blanc-gris, parce que la sobriété est un parti pris. Que la mascotte célèbre la fin des courses avec des confettis, parce qu’une corvée mérite d’être fêtée. Que le paywall n’apparaisse qu’après que la valeur a été prouvée, jamais avant.
Ces décisions ne se promptent pas. Elles se designent. L’IA a codé ce que j’avais décidé, et c’est cette direction qui rend l’expérience mémorable.

2. Feature First, Design Second

L’époque où l’on figeait tout le design sur Figma avant d’écrire une ligne de code est révolue. L’approche d’aujourd’hui consiste à se concentrer d’abord sur la fonctionnalité en s’appuyant sur des composants natifs ou des librairies standards. On stabilise l’expérience utilisateur, les interactions et le form factor de l’application directement dans le code, et on ne revient sur Figma que plus tard pour concevoir et réinjecter le look & feel final.

🛠️ L’exemple de Vet Companion

Par Maxime Frere, Principal Designer @ Source.paris

• Le projet : Un carnet de santé sur iOS (app native) pour centraliser le suivi médical (poids, vaccins, traitements) des chiens et des chats.

• Stack : Cursor + Subagents, Claude Opus 4.6, Xcode

• Durée : 3 jours intensifs pour arriver à une première beta.

• Statut : Beta publique

Pour ce projet, j’ai volontairement revu mon workflow en essayant de ne pas utiliser Figma. Avec une philosophie Feature First, j’ai codé l’interface directement en Swift UI via Cursor. Figma n’a servi qu’à ouvrir l’UI Kit Apple pour vérifier le nom exact de certains composants : une nécessité pour bien prompter l’IA. En designant dans le code, j’ai capitalisé sur le langage de design d’Apple, qui contient des animations fluides, l’adaptation au Dark Mode et une intégration seamless à l’écosystème iOS.

3. Le prompt magique n'existe pas : il vous faut une méthode

Les outils de vibe-coding poussent les utilisateurs à "prompter" directement leur idée, presque de manière instinctive. Nous recommandons au contraire de passer du temps à dialoguer avec une IA en mode orchestrateur, avant de toucher à un outil de coding.

Cette phase est indispensable pour clarifier le besoin, définir l'architecture technique et rédiger un PRD (Product Requirement Document). C'est quelque chose de commun à tous nos projets, pas seulement ceux présentés aujourd’hui. Un framework utile pour structurer cette étape : BMAD, une méthode open source qui organise le dialogue avec l'IA autour de rôles précis (Business Analyst, Architect, Developer…).

🛠️ L’exemple de La Comédie des Alpes

Par Olivier Chatel, Directeur général @ Source.paris

• Le projet : Une web app permettant au public d’un café-théâtre de choisir son siège sur une tablette et d’obtenir un billet physique imprimé sur place.

• Stack : ChatGPT-5, Lovable, Supabase, Cursor, GitHub

• Durée du projet : Environ 5 jours étalés sur une période d’un mois

• Statut : Utilisé au guichet du théâtre

Ce projet impliquait de créer une web app, avec un CMS pour gérer les séances en back, un plan de salle en front. Le tout capable de communiquer avec une imprimante à ticket de caisse.

Pour ce dernier point, l’IA a joué un rôle de véritable CTO : elle a guidé le choix du matériel (imprimante + routeur), la configuration réseau et l’intégration du SDK Epson dans la web app. Cursor a ensuite pris le relais de Lovable pour gérer la partie la plus technique, via des branches GitHub pour sécuriser l’environnement de production.

Si Lovable est un playground incroyable pour tester et itérer rapidement, il peut vite montrer ses limites en termes de coûts si le produit prend de l’ampleur (même chose avec Supabase). Aujourd’hui je privilégierais plutôt Cursor pour démarrer de nouveaux projets.

Le prompt “Pose-moi toutes les questions pertinentes pour comprendre mon besoin” reste un vrai game-changer. Il force à cadrer parfaitement le produit avant de coder quoi que ce soit.

4. La mémoire de l’IA est fragile : documentez et versionnez

Si un PRD ou le framework BMAD sont parfaits pour amorcer le projet, ils deviennent vite obsolètes : au fil des itérations, l’IA va naturellement s’en éloigner. Pour éviter qu’elle ne perde le contexte ou n’hallucine, il est crucial de documenter continuellement les progrès via des fichiers de référence synthétiques en Markdown et de sauvegarder vos avancées sur des branches Git.

🛠️ L’exemple de Dressmi

Par Guillem Cotcha, Product Designer @ Source.paris

• Le projet : Un dressing virtuel pour sauvegarder, catégoriser ses tenues et inspirations. Un projet iOS en développement depuis 2023, longtemps ralenti faute de temps et de compétences techniques.

• Stack : Perplexity (PO), Claude Code (CTO), Supabase, Figma MCP, Xcode

• Statut : En cours de développement

Ici, l’IA n’a pas servi à créer une app from scratch, mais à débloquer et refondre entièrement l’API d’un projet existant, en une seule session.

Rebâtir l’API d’un projet et la mettre en production très rapidement, c’est possible avec Claude. La maintenir sur la durée sans que l’IA ne perde le fil, c’est plus dur.

Pour remédier à ça, j’ai mis en place un véritable “écosystème de coding contextuel”. Perplexity agit comme mon PO pour la recherche et la constitution de documentation, et Claude comme mon CTO pour l’interpréter et l’exécuter. Surtout, le projet vit grâce à des fichiers Markdown (prd.md, design.md, _devLog) placés directement dans le dossier du code. J’y documente méticuleusement chaque erreur et chaque solution technique pour constituer une base de connaissance. L’IA vient lire ces fichiers comme une table des matières pour alimenter son contexte et maintenir la vision globale du projet.

Apprendre en construisant, ensemble

Nous avons fait le choix d’accompagner cette transition de façon concrète et structurée, car tous les designers de l’équipe ne sont pas exposés de la même manière à ces nouvelles pratiques dans les contextes clients. Si certains projets servent de terrains d’expérimentation en conditions réelles, nous sanctuarisons aussi des temps collectifs pour pratiquer, apprendre et progresser, en encourageant chacun à s’appuyer sur des projets personnels qui lui tiennent à cœur. Cela passe également par la prise en charge d’outils comme Cursor ou Lovable, pour donner à l’équipe les moyens d’apprendre en construisant.