Il y a quatre mois, j'ai choisi d'explorer une nouvelle facette de mon métier : concevoir une application mobile. Le prolongement naturel de ce que je construis depuis deux ans avec mes outils de prompt engineering, appliqué cette fois à un projet de plus grande ampleur, élaboré en collaboration avec un LLM plutôt que délégué à lui. DermaSens Essential en est aujourd'hui à sa huitième version. Les deux builds, iOS et Android, sont en production : le premier est en cours de vérification chez Apple, le second attend encore ses douze testeurs pour sortir du test fermé. L'application est désormais compatible iPad et tablette Android, au terme d'un chantier de layout qui m'a forcé à revoir des choix que je pensais acquis. Cette histoire-là mérite d'être racontée dans l'ordre, avec ses vraies étapes, plutôt que résumée à une ligne de succès.

Pourquoi DermaSens

J'ai depuis longtemps vécu avec des problèmes de peau et l'anxiété qui les accompagne. Puis le temps a redéfini ma perception : l'apparition d'un mélasma à l'été 2022, et l'hyperpigmentation qui l'a suivi, ont agi comme une vraie prise de conscience sur des années de négligence face au soleil. Depuis environ quatre ans, j'ai changé d'approche : protection systématique, routine sérieuse, un rapport à mon visage que j'ai choisi d'apprivoiser plutôt que d'ignorer.

DermaSens est né de cette expérience personnelle, pensée dès le départ comme un outil de suivi de l'évolution de la peau dans le temps, sans jugement esthétique, et volontairement inclusif au niveau du genre : l'anxiété liée à sa peau et à son visage ne se limite à aucun genre en particulier. Je répondais à ma propre problématique, en sachant que je ne serais probablement pas le seul concerné.

Étendre mon champ de compétence

Le développement a démarré sur Expo SDK 51, migré plus tard vers la version 54. Ce n'était pas mon premier projet mené avec un LLM comme collaborateur technique, mon activité repose déjà largement sur cette méthode, que ce soit pour des outils de conversion de données, un système de devis, ou l'infrastructure de mon propre site. Mais c'était la première fois que j'appliquais cette méthode au développement mobile natif, avec ses propres contraintes : architecture de composants, gestion d'état, cycles de build, arbitrages financiers sur les outils utilisés.

Avant d'écrire la moindre ligne de code, j'ai construit avec Claude tout un dossier de vision : personas, spécifications fonctionnelles, plusieurs pistes de business model, freemium, abonnement, achat unique, licence B2B pour les cliniques. Ce modèle a depuis évolué : l'application est aujourd'hui proposée gratuitement, la version 1.1 apportera de nouvelles fonctionnalités, et la réflexion actuelle penche plutôt vers un achat unique à un prix volontairement dérisoire, autour de 4,99 euros, que vers un abonnement. On a posé l'identité visuelle dès l'étape du dossier de vision : palette Sable, Blush, Mousse, Marine, typographie DM Sans pour le texte courant et DM Serif Text pour les titres. Rien n'était figé d'avance, tout s'est construit itération après itération, en testant des hypothèses et en écartant ce qui ne fonctionnait pas.

Ce qui a occupé le plus clair de mon temps à ce stade, ce n'était pas d'apprendre à écrire du code ligne par ligne, mais de structurer le travail : quel modèle mobiliser pour quelle tâche, comment découper les prompts pour rester dans un contexte gérable, comment organiser les fichiers et les responsabilités entre composants. Une vraie discipline d'ingénierie, appliquée à un domaine que je découvrais, avec des méthodes que je maîtrisais déjà.

La montée en complexité

Les mois suivants ont vu l'application monter en fonctionnalités. Un système éditorial centralisé pour gérer tous les textes de l'app à un seul endroit. Un système de routines personnalisées avec son propre store de configuration. La persistance des photos, copiées dans le répertoire de documents au moment de la sélection plutôt que référencées par un chemin temporaire. Des exports en CSV et en HTML. Des notifications avec une rotation sur sept jours pour ne pas répéter le même message en boucle.

À un moment du projet, j'ai organisé un handoff technique complet entre deux instances de Claude, avec un prompt de passation détaillé pour que la seconde reprenne le fil sans perdre le contexte. Un audit croisé effectué par cette seconde instance a mis au jour un bug de type "temporal dead zone" dans un composant, RoutineCard, que la première instance n'avait pas détecté. Un bon exemple de ce que veut dire piloter un développement sur la durée avec un LLM : ça fonctionne remarquablement bien, mais ça demande une vigilance méthodique à chaque étape, y compris pour auditer le travail d'une instance précédente.

En parallèle, l'activité tourne

Pendant que DermaSens avançait, je construisais aussi mon infrastructure professionnelle en tant que PromptCraft Creative : site vitrine, messagerie dédiée, outils de gestion administrative et comptable, système de devis automatisé.

Et puis un projet client est venu s'ajouter en parallèle, sur une problématique complètement différente, pour quelqu'un d'autre qui avait besoin de mon aide. Un vrai mandat, avec ses propres délais, qui a occupé une partie du temps que j'aurais pu consacrer à l'application. Ce n'était pas un détail annexe : c'était un arbitrage permanent entre le projet qui me tient à cœur et celui qui fait tourner l'activité.

Le virage Essential

À un moment, il a fallu se rendre à l'évidence : la version dense et personnelle de DermaSens, avec toute sa richesse fonctionnelle, n'était pas ce dont le grand public avait besoin. C'était mon outil à moi, construit pour répondre à ma propre expérience, mais pour toucher plus de monde, il fallait une version épurée, plus accessible, moins exigeante à prendre en main.

C'est là qu'est née DermaSens Essential. Pas un simple allègement technique, mais une vraie décision éditoriale : garder l'intention de départ, l'inclusivité, le suivi bienveillant de sa peau, mais retirer tout ce qui pouvait faire barrière à l'entrée pour quelqu'un qui découvre l'application pour la première fois.

Le mur du store

Une fois l'application prête, il a fallu affronter tout ce qu'implique une préparation de soumission store en conditions réelles. Icônes, icône adaptative Android, écrans de démarrage, gestion des zones sûres sur tous les formats d'écran. Un bug particulièrement retors sur iOS, lié aux changements de conteneur de l'application, faisait perdre le chemin des photos stockées : la correction a consisté à ne stocker que le nom de fichier plutôt que le chemin complet.

J'ai construit tout un pipeline en Python avec Pillow pour générer les visuels du store : icône, icône adaptative, écrans de démarrage, feature graphic, icône Play Store, en itérant jusqu'à ce que tout corresponde à l'identité visuelle de l'onboarding. Une fois cette étape passée, je pensais que le plus dur était derrière moi. La commande de build ressemblait à quelque chose d'aussi simple que ça :

eas build --platform ios --profile production

Simple en apparence. La suite allait me prouver le contraire.

Premier rejet

Apple a rejeté la soumission au titre de la Guideline 4.0. Le motif : sur un iPad Air 11 pouces M3, en mode de compatibilité iPhone, du contenu de l'écran d'onboarding se retrouvait masqué par un bouton flottant. Un défaut d'affichage, pas un bug fonctionnel, mais suffisant pour bloquer toute la soumission.

Le point notable n'était pas tant le rejet en lui-même, c'est monnaie courante dans ce processus, que le fait de rater quelque chose d'aussi visible sur un appareil aussi répandu qu'un iPad, après des mois de travail sur les moindres détails visuels de l'onboarding.

La fausse bonne solution

Le correctif semblait évident : rendre les six écrans d'onboarding scrollables plutôt que fixes, avec un padding dynamique en bas pour laisser la place au bouton. Sur le papier, ça réglait le problème. Le test sur BrowserStack en simulant un iPhone SE, la configuration qui nous servait de référence jusque-là, confirmait la correction.

En creusant, le vrai problème est apparu : iPadOS 26 a changé la façon dont les applications conçues uniquement pour iPhone s'affichent sur iPad, avec un nouveau mode appelé "Full Screen Apps". Notre méthode de test de référence était devenue obsolète sans qu'on s'en aperçoive. On ne testait plus dans les conditions réelles rencontrées par le reviewer Apple sur son iPad Air 11 pouces M3.

Deuxième rejet, même défaut

Une fois la méthode de test corrigée pour refléter les vraies conditions d'affichage en mode Full Screen Apps, le deuxième rejet est tombé avec exactement le même défaut, visuellement identique au premier. Recommencer avec les bonnes conditions de test pour retomber sur le même mur, ça a été le moment le plus exigeant de tout ce chantier iPad. La méthode était corrigée, et le problème persistait.

La remise en question

C'est à ce moment qu'a été prise la vraie décision architecturale : abandonner le bouton flottant au profit d'un pied de page intégré à l'écran. Sur le principe, ça réglait le problème d'affichage. Dans les faits, ça entrait en tension directe avec l'identité visuelle du produit, celle qu'on avait mis des mois à peaufiner.

Il y a eu une vraie remise en question, honnête, sur le travail déjà livré. Retour à zéro sur les espacements de chaque écran d'onboarding. Ce n'était pas un ajustement mineur, c'était remettre en question des choix qu'on pensait acquis. Le compromis final s'est construit entre la contrainte technique imposée par Apple et l'identité visuelle à préserver. Pas la version qui aurait été choisie en premier si le choix s'était posé dès le départ, mais celle qui fonctionne, sur iPhone comme sur iPad.

Pendant ce temps, Android

En parallèle de ce chantier iOS, il fallait aussi recruter les douze testeurs requis par Google Play pour le test fermé Android. La première approche, une collecte manuelle des emails, s'est vite révélée être un frein plus qu'un facilitateur : trop de friction pour les personnes intéressées, trop de gestion manuelle de mon côté. Le passage à un Google Group en libre-service a réglé le problème d'un coup, même si le recrutement des douze testeurs est toujours en cours à l'heure où j'écris.

Où j'en suis

Voilà où j'en suis au moment d'écrire ces lignes. Les deux builds sont en production : la version iOS est en cours de vérification chez Apple, la version Android attend encore ses douze testeurs pour sortir du test fermé. Le travail de layout, d'espacement, et le passage du bouton flottant à un pied de page fixe ont permis à DermaSens Essential d'être désormais compatible iPad et tablette Android.

Je ne connais pas encore l'issue de la vérification Apple, mais l'itération est maîtrisée : je sais précisément ce qui a été corrigé, pourquoi, et ce qui reste à vérifier. La suite, avec le résultat de cette soumission, viendra dans la Partie 2.