Développement mobile à l'ère où l'IA écrit le code

Que signifie vraiment « l'IA écrit la plupart du code »

Quand on dit « l'IA écrira la plupart du code », on n'entend pas souvent que les décisions produit complexes disparaissent. On veut plutôt dire qu'une large part du travail de production routinier devient générée par machine : écrans, raccordements entre couches, traitement de données répétitif et l'ossature qui transforme une idée en quelque chose qui compile.

Ce que « la plupart du code » inclut typiquement

Dans les équipes mobiles, les gains les plus faciles sont souvent :

• Code UI et layout : hiérarchies de vues, widgets, styles et attributs d'accessibilité en première passe.
• Glue code : wrappers réseau, mapping JSON, wiring d'état, routes de navigation et configuration d'injection de dépendances.
• Tests et fixtures : squelettes de tests unitaires, données factices et tests d'intégration de base couvrant le happy path.
• Docs et commentaires : README, notes d'utilisation d'API et explications inline — utiles, mais à vérifier.

Autocomplétion vs chat vs codage agentique

• Autocomplétion accélère ce que vous savez déjà vouloir taper. C'est local, incrémental et généralement le plus sûr.
• Codage par chat est mieux pour générer un draft à partir d'une description ("construis un écran de réglages avec des bascules"), mais il peut manquer des contraintes spécifiques à l'app.
• Codage agentique tente d'exécuter des tâches multi‑étapes (modifier plusieurs fichiers, lancer des tests, corriger des erreurs). Cela peut faire gagner du temps, mais augmente aussi le risque de changements inattendus.

Attentes réalistes

L'IA excelle à produire des bons drafts rapidement et est faible pour bien gérer chaque détail : cas limites, bizarreries de plateforme et nuances produit. Prévoyez d'éditer, supprimer et réécrire des parties — souvent.

Ce que les humains doivent encore décider

Les personnes conservent la propriété des décisions qui façonnent l'app : exigences, limites de confidentialité, budgets de performance, comportement hors ligne, standards d'accessibilité et arbitrages entre rapidité, qualité et maintenabilité. L'IA peut proposer des options, mais elle ne peut pas choisir ce qui est acceptable pour vos utilisateurs ou votre entreprise.

Le nouveau flux mobile : des prompts aux releases expédiées

Les équipes mobiles commenceront toujours par un brief — mais la passation change. Plutôt que de dire « écris les écrans A–D », vous traduirez l'intention en entrées structurées que l'IA pourra transformer de façon fiable en pull requests.

Une boucle E2E future

Un flux courant ressemble à :

1. Brief : un court récit (qui est l'utilisateur, ce qu'il veut faire, critères de succès).
2. Spec : exigences structurées (user stories, critères d'acceptation, événements analytics, états d'erreur, notes d'accessibilité).
3. Paquet de prompts : la spec plus les contraintes (règles d'architecture, composants existants, style de code, contrats API).
4. PRs générées : l'assistant propose des PRs scoped (UI, gestion d'état, wiring API, tests).
5. Revue humaine : les développeurs relisent les diffs comme aujourd'hui — sauf qu'une plus grande part vient de l'IA.
6. Validation & release : CI, tests sur appareils, checks QA, puis déploiement progressif.

Le changement clé est que les exigences deviennent des données. Plutôt que d'écrire un long doc et d'espérer que tout le monde l'interprète de la même façon, les équipes standardisent des templates pour :

• Comportement écran par écran (y compris états vides/loading/erreur)
• Exemples de requêtes/réponses API et cas limites
• Exigences non fonctionnelles (support hors ligne, budgets de performance, localization)

Itération : régénérer, comparer, valider

La sortie IA est rarement « une et terminée ». Les équipes saines traitent la génération comme une boucle itérative :

• Régénérer de petites portions quand quelque chose cloche (un écran, un reducer, un appel API).
• Comparer des alternatives (deux PR pour la même feature) et choisir l'approche la plus propre.
• Valider avec des vérifications automatiques : tests unitaires, snapshot tests, linting et une courte passe manuelle sur appareils réels.

C'est plus rapide que de réécrire, mais seulement si les prompts sont cadrés et si les tests sont stricts.

Conserver une seule source de vérité

Sans discipline, prompts, chats, tickets et code divergent. La solution est simple : choisissez un système de référence et appliquez‑le.

• Les tickets (Jira/Linear/etc.) contiennent exigences et critères d'acceptation.
• Les specs vivent aux côtés du repo (ex. /docs/specs/...) et sont référencées par les PRs.
• Les Architecture Decision Records (ADRs) consignent le « pourquoi », afin que les générations futures suivent les mêmes règles.

Chaque PR générée par l'IA devrait renvoyer au ticket et à la spec. Si le code change le comportement, la spec change aussi — ainsi le prochain prompt part de la vérité, pas de la mémoire.

Choisir des outils IA pour les équipes mobiles (sans chaos)

Les outils IA peuvent sembler interchangeables jusqu'au moment d'expédier une vraie release iOS/Android, où l'on réalise que chacun change la façon de travailler, quelles données quittent l'organisation et la prévisibilité des sorties. L'objectif n'est pas « plus d'IA » mais moins de surprises.

Connaître les types d'outils (et leurs atouts)

• Assistants IDE : complétions inline et refactors dans Xcode/Android Studio/VS Code. Idéaux pour petits edits, patterns répétitifs et apprentissage d'APIs inconnues.
• Outils de chat : aide conversationnelle pour debug, questions d'architecture et génération de snippets. Utile, mais facile de perdre le contexte et les décisions.
• Agents sensibles au codebase : peuvent parcourir votre repo, proposer changements multi‑fichiers et ouvrir des PRs. Fort effet de levier, mais à contraindre par des standards.
• Bots CI : tournent dans les pipelines pour suggérer des corrections, générer des changelogs ou résumer des échecs de tests. Utile pour la cohérence et l'auditabilité.

Critères de sélection qui comptent vraiment

Priorisez les contrôles opérationnels plutôt que le marketing du modèle :

• Mode confidentialité (pas d'entraînement sur vos données, options de redaction, rétention claire)
• Limites de contexte (peut‑il lire assez de votre repo pour être correct, ou va‑t‑il halluciner autour de fichiers manquants ?)
• Journaux d'audit (qui a prompté quoi, quel code a été généré, qu'est‑ce qui a été mergé)
• Contrôles de coût (par siège vs usage, plafonds et alertes)

Si vous voulez un exemple concret d'approche « workflow-first », des plateformes comme Koder.ai se concentrent sur la transformation de chats structurés en sorties applicatives réelles — web, backend et mobile — tout en gardant des garde‑fous comme la planification et le rollback à l'esprit. Même si vous n'adoptez pas une plateforme bout en bout, ce sont les capacités à benchmarker.

Où les outils tournent : local, cloud ou self‑hosted

• Local : feedback le plus rapide, meilleur pour le code sensible, mais tailles de modèles limitées.
• Cloud : modèles souvent plus puissants et configuration plus simple, mais demande confiance et gouvernance.
• Self‑hosted : meilleur contrôle et conformité, mais vous gérez uptime, mises à jour et scalabilité.

Onboarding pour éviter la prolifération d'outils

Créez un petit « playbook IA » : templates de projets starter, guides de prompts approuvés (ex. « générer un widget Flutter avec notes d'accessibilité ») et standards de codage imposés (règles de lint, conventions d'architecture et checklists PR). Associez‑y une revue humaine obligatoire, et référez‑le dans la doc d'équipe (par ex. /engineering/mobile-standards).

Architecture et design : point de levier quand le code est bon marché

Quand l'IA peut générer écrans, view models et clients API en minutes, le goulot devient les décisions qui structurent tout le reste : comment l'app est organisée, où vivent les responsabilités et comment le changement circule en sécurité dans le système.

Rendre les frontières explicites (pour que l'IA s'y tienne)

L'IA remplit bien les patterns ; elle est moins fiable quand le pattern est implicite. Des frontières claires évitent que du code « utile » fasse fuiter des préoccupations à travers l'app.

Pensez en termes de :

• Modules : fonctionnalités séparées (ex. Paiements, Profil) et code plateforme partagé (Networking, Design System).
• Couches : UI, logique domaine/métier et accès aux données. Gardez des API publiques réduites pour chaque couche.
• Navigation : définissez routes et ownership (navigation possédée par la feature vs router central). Évitez les deep links ad hoc.
• Gestion d'état : choisissez une approche principale et documentez‑la. Mélanger des patterns (un peu de Redux ici, un peu de MVVM là) invite à de l'incohérence dans le code généré.

L'objectif n'est pas « plus d'architecture » mais moins d'endroits où tout peut arriver.

Utiliser des scaffolds et générateurs pour contraindre la sortie

Si vous voulez du code IA cohérent, donnez‑lui des rails :

• Un scaffold de feature (structure de dossiers, conventions de nommage, classes/interfaces de base)
• Templates pour écrans, tests et appels API
• Un package design system avec composants réutilisables

Avec un scaffold, l'IA peut générer « un autre écran FeatureX » qui ressemble et se comporte comme le reste de l'app — sans que vous n'ayez à réexpliquer les décisions à chaque fois.

Documentation légère et réellement utilisée

Gardez les docs courtes et axées sur la décision :

• Un diagramme d'architecture par appli (ou par domaine majeur)
• ADRs pour choix clés (navigation, état, stratégie hors ligne)
• Une page conventions courte : noms, layout de fichiers, gestion d'erreur, logging, événements analytics

Ces documents servent de référence à l'équipe — et à l'IA — pendant les revues de code, rendant le code généré prévisible plutôt que surprenant.

L'UX et la réflexion produit deviennent les principaux différenciateurs

Quand l'IA peut générer des écrans compétents, du code réseau et même la gestion d'état à la demande, « avoir une app » cesse d'être l'obstacle principal. La différenciation bascule sur ce que vous construisez, pourquoi et à quelle vitesse vous apprenez : choix UX, insights produit et rapidité d'apprentissage par itération.

Transformer le feedback en tâches exploitables par l'IA

Le feedback utilisateur est souvent vague ("c'est confus", "trop d'étapes"). La compétence produit consiste à le traduire en tickets précis que l'IA peut exécuter sans deviner. Une structure utile :

• But utilisateur (ce qu'il veut accomplir)
• Friction observée (où il bute)
• Métrique de succès (ce que signifie « mieux »)
• Contraintes (accessibilité, performance, patterns platforme)
• Critères d'acceptation (résultats testables)

Exemple : plutôt que « améliorer l'onboarding », écrivez : « Réduire le time-to-first-success de 90s à 45s en retirant la création de compte de l'étape 1 ; ajouter « Continuer en invité » ; assurer les labels VoiceOver sur tous les contrôles ; tracker l'événement onboarding_completed avec la durée. » Ce niveau de clarté rend le code généré beaucoup plus fiable — et les revues plus rapides.

Les design systems deviennent des contraintes réutilisables, pas juste de l'esthétique

À mesure que le code devient moins coûteux, la cohérence devient la partie coûteuse. Un design system bien défini (composants, espacements, typographie, règles de motion, guidelines de contenu) sert de contrat partagé entre produit, design et ingénierie — et d'ensemble de contraintes pour les prompts IA.

L'accessibilité s'inscrit naturellement ici : tokens de contraste de couleur, cibles tactiles minimales, règles de taille dynamique, états de focus et conventions de nommage pour lecteurs d'écran. Si ces règles sont standardisées, l'IA peut générer des UI conformes par défaut plutôt que « à corriger plus tard ».

Analytics et expériences sont des éléments de travail de première classe

Dans un workflow IA, l'instrumentation n'est pas optionnelle ; c'est la façon dont vous apprenez. Traitez événements analytics, entonnoirs et expériences comme des features :

• Définissez noms d'événements, propriétés et timings en même temps que les exigences UI
• Spécifiez variants d'expérience comme changements UX explicites (pas « A/B test onboarding » vague)
• Reliez chaque changement à une décision : quel résultat fera qu'on garde, revert ou itère ?

C'est là que les équipes prennent de l'avance : pas en expédiant plus de code, mais en posant de meilleures questions, capturant les bons signaux et itérant plus vite que la concurrence.

Tests et QA quand le code est majoritairement généré

Quand l'IA produit écrans, couches de données et glue code en quelques minutes, le risque n'est pas des mauvais développeurs. Le risque est le volume non revu. Plus de changements par semaine signifie plus d'occasions de régressions subtiles — vous avez donc besoin de contrôles automatisés plus solides, pas moins.

Une pile de tests équilibrée (et ce que chaque niveau détecte)

Tests unitaires restent le filet de sécurité le moins cher. Ils vérifient des règles petites (formatage d'un prix, validation d'un formulaire, mapping de champs API) et rendent les refactors sûrs quand l'IA réécrit des blocs de logique.

Tests d'intégration protègent les jonctions : réseau + cache, flows d'auth, comportement hors ligne et flags de fonctionnalité. Le code généré fonctionne souvent sur le happy path, mais les tests d'intégration dévoilent timeouts, retries et cas limites.

Tests UI (appareil/émulateur) confirment que de vrais utilisateurs peuvent compléter des parcours clés : inscription, paiement, recherche, permissions et deep links. Concentrez‑les sur des flows à haute valeur — trop de tests UI fragiles vous ralentiront.

Snapshot testing peut aider pour les régressions visuelles, mais a des écueils : versions OS, polices, contenu dynamique et animations génèrent des diffs bruyants. Utilisez les snapshots pour des composants stables et préférez des assertions sémantiques (ex. « le bouton existe et est enabled ») pour les écrans dynamiques.

Génération de tests assistée par l'IA — utile, mais à vérifier

L'IA peut rédiger des tests rapidement, surtout pour les cas répétitifs. Traitez les tests générés comme le code généré :

• Assurez‑vous que le test affirme un comportement, pas un détail d'implémentation.
• Vérifiez qu'il échoue si vous cassez volontairement la fonctionnalité.
• Supprimez les « asserts sans sens » (ex. vérifier qu'une valeur n'est pas null sans contexte).

Portes de qualité qui montent en charge avec la production IA

Ajoutez des gates automatiques en CI pour que chaque changement respecte un socle :

• Linting + formatage pour garder la consistance et réduire les frictions de revue.
• Vérifications de types (lorsque disponibles) pour attraper mauvais mappings de données et nullabilité.
• Seuils de couverture pour modules critiques (auth, paiements, sync), pas pour toute l'app.
• Sélection de tests (smoke vs suite complète) pour pouvoir expédier vite sans sacrifier la sécurité.

Avec l'IA écrivant plus de code, la QA devient moins une vérification manuelle ponctuelle et plus la conception de garde‑fous qui rendent les erreurs difficiles à livrer.

Sécurité, confidentialité et conformité à l'ère du code généré par l'IA

Quand l'IA génère de larges portions de votre app, la sécurité n'est pas « automatisée automatiquement ». Elle est souvent externalisée aux valeurs par défaut — et les valeurs par défaut sont l'origine de nombreuses brèches mobiles. Traitez la sortie IA comme du code provenant d'un nouveau prestataire : utile, rapide et toujours à vérifier.

Risques typiques dans le code généré par l'IA

Les modes d'échec courants sont prévisibles, ce qui est une bonne nouvelle — vous pouvez concevoir des checks pour eux :

• Valeurs par défaut non sécurisées : paramètres réseau permissifs, validation TLS faible, absence de certificate pinning ou permissions trop larges.
• Fuite de secrets : clés API hardcodées, copiées d'exemples ou envoyées dans les logs/analytics.
• Dépendances risquées : introduction de paquets non vérifiés, bibliothèques obsolètes ou dépendances transitoires avec CVE connues.
• Erreurs d'auth et de gestion des données : stockage de tokens en clair, mauvaise gestion des refresh flows, ou mise en cache de réponses sensibles.

Confidentialité : prompts, code et données

Les outils IA peuvent capturer prompts, extraits de code, stack traces et parfois des fichiers entiers pour fournir des suggestions. Cela pose des questions de confidentialité et de conformité :

• Les prompts et le code source sont-ils utilisés pour entraîner le modèle ?
• Où les données sont‑elles traitées (région) et combien de temps sont‑elles conservées ?
• Les développeurs pourraient‑ils coller des données de production, logs ou identifiants utilisateurs dans des prompts ?

Établissez une règle : ne jamais coller de données utilisateur, credentials ou clés privées dans un assistant. Pour des applications réglementées, préférez des outils offrant des contrôles entreprise (rétention des données, journaux d'audit, option de refus d'entraînement).

Pièges spécifiques au mobile

Les apps mobiles ont des surfaces d'attaque uniques que l'IA peut manquer :

• Usage du Keychain/Keystore : stockez les tokens dans le Keychain iOS / Android Keystore, pas dans SharedPreferences ou des fichiers locaux.
• Deep links et app links : validez les URLs entrantes, protégez contre les open redirects et évitez d'exposer des écrans sensibles.
• Flows d'auth : utilisez les navigateurs système pour OAuth (ASWebAuthenticationSession / Custom Tabs), gérez state/nonce et verrouillez les redirect URIs.

Pratiques qui vous gardent en sécurité

Construisez un pipeline reproductible autour de la sortie IA :

• Threat modeling léger par feature (quelles données, quels attaquants, que peut‑il se passer ?)
• SAST dans la CI pour défauts courants et API non sécurisées
• DAST pour API et flows d'auth sur des builds staging
• Scan de dépendances + allowlists pour paquets

L'IA accélère le codage ; vos contrôles doivent accélérer la confiance.

Performance et fiabilité sur des appareils réels

L'IA peut générer du code qui a l'air propre et passe des tests basiques, mais qui saccade sur un Android de 3 ans, vide la batterie en arrière‑plan ou craque sur un réseau lent. Les modèles optimisent souvent pour la correction et les patterns communs — pas pour les contraintes désordonnées des appareils périphériques, du throttling thermique et des bizarreries fournisseurs.

Où le code généré nuit généralement à la perf

Surveillez les « valeurs par défaut raisonnables » qui ne le sont pas sur mobile : logs trop verbeux, re-renders fréquents, animations lourdes, listes non bornées, polling agressif ou parsing JSON lourd sur le thread principal. L'IA peut aussi choisir des bibliothèques pratiques qui ajoutent du coût au démarrage ou augmentent la taille binaire.

Profiling : l'essentiel à mesurer à chaque release

Traitez la performance comme une feature avec des checks reproductibles. À minima, profilez :

• Temps de démarrage (cold et warm) : temps jusqu'au premier écran signifiant.
• Mémoire : croissance dans le temps, comportement du cache d'images et fuites.
• Batterie : tâches en arrière‑plan, usage de la localisation, wakelocks, gestion des push.
• Réseau : volume de requêtes, retries, tailles de payload, cache et timeouts.

Répétez ces mesures sur un Android bas de gamme représentatif et un iPhone plus ancien, pas seulement sur les flagships récents.

Fragmentation et support OS = problèmes de fiabilité

La fragmentation des appareils se manifeste par des différences de rendu, des crashes spécifiques aux fournisseurs, des comportements de permissions changeants et des dépréciations d'API. Définissez clairement vos versions OS supportées, maintenez une matrice de devices explicite et validez les flows critiques sur du hardware réel (ou une ferme de devices fiable) avant de livrer.

Budgets de performance + régressions automatisées en CI

Définissez des budgets de performance (ex. max cold start, max RAM après 5 minutes, max wakeups background). Ensuite, gatez les PRs avec des benchmarks automatisés et des seuils de crash‑free sessions. Si un changement généré augmente une métrique, la CI doit échouer avec un rapport clair — pour que « l'IA l'a écrit » ne devienne jamais une excuse pour des releases lentes ou instables.

Propriété du code, licences et hygiène IP

Quand l'IA génère la majeure partie de votre app, le risque légal vient rarement du modèle « possédant » quoi que ce soit — il vient des pratiques internes négligentes. Traitez la sortie IA comme toute autre contribution tierce : relisez, suivez et rendez la propriété explicite.

Qui « possède » le code généré par l'IA dans l'entreprise ?

En pratique, votre entreprise possède le code créé par des employés ou contractors dans le cadre de leur travail — qu'il ait été tapé à la main ou produit avec un assistant IA — tant que vos accords l'énoncent. Clarifiez‑le dans le handbook ingénierie : les outils IA sont autorisés, mais le développeur reste l'auteur de référence et responsable de ce qui est expédié.

Pour éviter la confusion plus tard, gardez :

• Une politique exigeant que tous les changements générés par l'IA passent par la revue PR normale
• L'attribution des commits au contributeur humain (plutôt qu'à un compte « bot » générique), avec une note optionnelle « généré avec un assistant » si nécessaire

Risques de licences open source et d'attribution

L'IA peut reproduire des patterns reconnaissables provenant de dépôts populaires. Même si c'est involontaire, cela peut créer des problématiques de « contamination de licence », surtout si un extrait ressemble à du code GPL/AGPL ou contient des en‑têtes de copyright.

Bonne pratique : si un bloc généré semble particulièrement spécifique, cherchez‑le (ou demandez à l'IA de citer ses sources). Si vous trouvez une correspondance, remplacez‑le ou conformez‑vous à la licence et aux obligations d'attribution.

Inventaire de dépendances et workflow d'approbation

La plupart des risques IP entrent via les dépendances, pas votre code. Maintenez un inventaire permanent (SBOM) et un chemin d'approbation pour les nouveaux paquets.

Workflow minimum :

• Scan automatisé des dépendances en CI
• Une checklist légère « nouvelle dépendance » (licence, maintenance, support plateforme)
• Une source de vérité pour les bibliothèques approuvées

Utiliser des SDK tiers et snippets en sécurité

Les SDK analytics, publicités, paiements et auth ont souvent des termes contractuels. Ne laissez pas l'IA "ajouter utilement" ces SDK sans revue.

Directives :

• N'ajoutez que des SDKs de la liste approuvée ; sinon, exigez une validation sécurité + juridique
• Préférez la doc d'intégration officielle ; stockez les liens dans /docs du repo
• Ne collez jamais de code d'origines inconnues en production ; traitez les snippets comme des dépendances

Pour les templates de rollout, liez votre politique dans /security et faites‑la appliquer par des checks PR.

Comment les rôles et carrières des développeurs vont changer

Quand l'IA génère de larges morceaux de code mobile, les développeurs ne disparaissent pas — ils passent de « taper du code » à « diriger des résultats ». Le travail quotidien s'oriente vers la spécification précise du comportement, la revue de ce qui est produit et la vérification sur appareils réels et scénarios utilisateurs réels.

D'implémenteurs à éditeurs et enquêteurs

Attendez‑vous à passer plus de temps sur :

• Rédaction d'exigences précises et de cas limites (ce qui doit arriver, pas seulement comment)
• Relecture de diffs comme un éditeur : cohérence, maintenabilité et complexité cachée
• Vérification via tests, runs sur appareils, logs et rapports de crash

En pratique, la valeur se déplace vers décider quoi construire ensuite et repérer des problèmes subtils avant l'App Store/Play Store.

Compétences durables qui resteront pertinentes

L'IA peut proposer du code, mais elle ne peut pas entièrement posséder les arbitrages. Les compétences qui s'accroissent incluent : debugging (lire des traces, isoler des causes), pensée système (interaction app/backend/analytics/OS), communication (transformer l'intention produit en specs non ambiguës) et gestion du risque (sécurité, confidentialité, fiabilité et stratégie de rollout).

Les standards de revue de code doivent évoluer

Si du code à l'apparence correcte devient bon marché, les revues doivent porter sur des questions de haut niveau :

• Intention: le code correspond‑il au besoin produit et à l'intention UX ?
• Tests: y a‑t‑il des tests unitaires/intégration significatifs couvrant des cas réalistes ?
• Menaces: fuites de confidentialité, stockage non sécurisé, permissions inutiles, risques d'injection ?

Mettez à jour les checklists de revue et n'acceptez pas « l'IA dit que c'est OK » comme justificatif.

Conseils pour les juniors

Utilisez l'IA pour apprendre plus vite, pas pour éviter les fondamentaux. Continuez à construire des bases en Swift/Kotlin (ou Flutter/React Native), réseau, gestion d'état et debugging. Demandez à l'assistant d'expliquer des arbitrages, puis vérifiez en écrivant de petits morceaux vous‑même, en ajoutant des tests et en faisant des revues avec un senior. L'objectif est de devenir quelqu'un qui sait juger du code — surtout quand ce n'est pas vous qui l'avez écrit.