De l’écriture de Kotlin à la direction des agents : le nouveau rôle de l’ingénieur mobile

Les agents de codage ne se contentent plus de terminer la ligne de code demandée. Ils explorent un dépôt, planifient des modifications, éditent plusieurs fichiers, exécutent la compilation, analysent les erreurs et tentent à nouveau. Cela soulève une question délicate pour un ingénieur mobile : si l’agent écrit la majeure partie du code Kotlin, s’agit-il encore de développement Android, ou est-ce simplement devenu l’écriture de prompts à l’intérieur d’un IDE ? Cet article affirme que aucune de ces deux catégories ne convient, et explique en quoi consiste plutôt ce rôle : rédiger des spécifications précises, concevoir le contexte dans lequel l’agent travaille, encodifier l’architecture sous forme de contraintes, et vérifier des résultats que l’on n’a pas soi-même tapés.

Les exemples sont spécifiques à Android, mais les principes s’appliquent directement à React Native, ainsi qu’aux équipes web et backend utilisant ce type d’outils.

Jusqu’où sont parvenus les assistants de codage

Le flux de travail classique d’Android est familier : ouvrir Android Studio, créer une classe, écrire du Kotlin, gérer Gradle, diagnostiquer des plantages via Logcat, tester sur un appareil et soumettre une demande de fusion.

L’aide basée sur l’IA s’est inscrite progressivement dans ce flux de travail. D’abord, elle a complété des lignes individuelles, puis des fonctions entières, et enfin des classes complètes. Les outils actuels agissent comme des agents. Au moment de la rédaction, plusieurs produits décrivent explicitement cette fonctionnalité :

• Gemini Agent Mode dans Android Studio accepte un objectif de développement de haut niveau, élabore un plan, invoque des outils, modifie plusieurs fichiers, construit le projet et itère en cas d’échec d’une étape.
• Cursor’s Agent explore une base de code, modifie plusieurs fichiers, exécute des commandes en terminal et corrige les erreurs tout en accomplissant une tâche, plutôt que de proposer simplement la ligne suivante.

OpenAI Codex s’exécute depuis la terminale en tant qu’agent de codage capable de lire, modifier et exécuter du code.

Les fonctionnalités des produits dans ce domaine évoluent rapidement, il est donc nécessaire de consulter la documentation actuelle de l’outil utilisé par votre équipe. La direction générale, cependant, est claire.

Le travail progresse vers le haut de la pile technologique

Un modèle mental utile est celui d’une échelle des activités d’ingénierie, allant des tâches les plus mécaniques en bas aux tâches nécessitant le plus de jugement en haut :

Write code
   ↓
Understand code
   ↓
Design architecture
   ↓
Define requirements
   ↓
Make engineering decisions
   ↓
Validate behavior
   ↓
Own the product

Les agents deviennent de plus en plus compétents pour les tâches de base. Cela ne rend pas la saisie et la lecture de code inutiles, mais cela change leur valeur. Une implémentation standard d’un répertoire qui prendrait une demi-heure à la main peut être générée en quelques secondes. Rédiger manuellement dix écrans Compose presque identiques est fastidieux ; un agent peut modifier les fichiers concernés et gérer les parties répétitives. Une simple erreur de compilation peut vous faire perdre plusieurs minutes, tandis qu’un agent lit le message, trouve le code en cause, le corrige, reconstruit et passe à autre chose.

Le résultat global est qu’un ingénieur consacre moins de temps à la création de code et plus de temps à choisir quels codes doivent exister en premier lieu.

Un bon prompt est en réalité une spécification

Prenons une demande de produit typique : ajouter une file d’attente de téléchargement à l’application. Un ingénieur Android expérimenté transforme mentalement cette phrase en un design en couches :

Database
    ↓
Repository
    ↓
Use Cases
    ↓
ViewModel
    ↓
UI State
    ↓
UI
    ↓
Background execution
    ↓
Notifications

Un développeur peut maintenant mettre en œuvre une grande partie de cette architecture, mais la qualité du résultat dépend fortement de ce que vous avez demandé. Comparez une instruction de trois mots (“ajouter une file d’attente de téléchargement”) avec quelque chose comme ceci :

Créez une file d’attente capable de gérer plusieurs téléchargements et de conserver ses données entre les lancements, avec le soutien de Room et WorkManager pour effectuer le travail. Suivez l’avancement en mémoire plutôt que d’enregistrer chaque mise à jour dans la base de données. Lorsque le processus est arrêté, restaurez les téléchargements en attente et actifs. Le ViewModel doit publier un StateFlow uniquement en lecture. Aucun type du framework Android ne doit figurer dans la couche de domaine. Couvrez les changements d’état de la file d’attente ainsi que la récupération en cas d’échec à l’aide de tests unitaires. Ne modifiez pas les entités Room qui n’ont aucun rapport avec les téléchargements.

Appeler la deuxième version un « prompt amélioré » en sous-estime ses capacités. Il s’agit d’une spécification technique : elle définit la technologie de persistance, le mécanisme d’exécution en arrière-plan, une décision liée aux performances (ne pas écrire chaque mise à jour de progression sur le disque), un critère de résilience (survivre à la fermeture du processus), un contrat API (StateFlow immuable), une règle de stratification, le champ d’application des tests ainsi qu’un rayon d’impact explicite. Chacune de ces clauses reflète des connaissances spécifiques à Android que l’agent ne peut pas déduire simplement en ajoutant une file d’attente de téléchargement.

La leçon à retenir est que l’ingénieur ne disparaît pas ; il devient plutôt la personne capable de traduire une demande vague émanant du produit en une description précise d’un système technique.

Prompting versus ingénierie

Ces deux rôles posent des questions différentes. Celui qui se concentre sur l’encadrement des requêtes se demande comment amener le modèle à produire un résultat donné. L’ingénieur, quant à lui, veut savoir ce qu’il faut construire, pour quelle raison, dans quelles contraintes, et comment on saura que cela fonctionne.

Supposons qu’un agent vous remette ce ViewModel :

class DownloadViewModel(
    private val repository: DownloadRepository
) : ViewModel() {
    val downloads = repository.downloads
}

Il se compile et s’exécute sans problème. Un développeur Android expérimenté a néanmoins une liste de questions avant d’accepter ce code :

• downloads est-il un Flow classique ou un StateFlow, et quel collecteur est déclenché par chacun ?
• Où se trouve la source unique de vérité pour l’état des téléchargements ?
• Qu’est-ce qui survit à la fermeture du processus ?
• Chaque mise à jour de progression déclenche-t-elle une écriture dans Room ?
• Que se passe-t-il lorsque deux téléchargements s’achèvent en même temps ?
• Comment la suppression d’une tâche est-elle modélisée ?

WorkManager peut-il redémarrer ce travail, et l’état le reflète-t-il ?

Que se passe-t-il en cas de perte de connexion réseau ?

Comment le système se comporte-t-il si l’utilisateur arrête forcément l’application ?

Le répertoire est-il sécurisé du point de vue des cycles de vie ?

Les événements UI ponctuels sont-ils conservés séparément de l’état ?

Comment cela fonctionne-t-il sur des appareils de basse gamme ?

Générer la classe est simple. Interroger le système qui l’entoure constitue la partie difficile, et il est bien plus ardu de l’automatiser.

Le cycle de développement agent

Le cycle traditionnel oblige le développeur à suivre étape par étape le chemin critique :

Requirement
    ↓
Developer writes code
    ↓
Build
    ↓
Error
    ↓
Developer investigates
    ↓
Fix
    ↓
Test
    ↓
PR

Avec un agent intermédiaire, le cycle change. Le développeur définit l’objectif au début et est responsable de la revue et de la validation à la fin, tandis que l’agent gère les cycles d’exploration, d’édition et de correction entre-temps :

Developer defines goal
        ↓
AI Agent explores codebase
        ↓
AI creates plan
        ↓
AI modifies files
        ↓
AI runs build/tests
        ↓
AI observes result
        ↓
AI fixes problems
        ↓
Developer reviews
        ↓
Developer validates behavior
        ↓
Ship

La documentation du fournisseur décrit le même schéma. Le Mode Agent d’Android Studio est présenté comme un processus de planification, d’appel d’outils, de modification de fichiers et d itération sur les résultats. Cursor décrit son agent comme un modèle capable de raisonner, des outils lui permettant de rechercher et d’éditer des fichiers ou d’exécuter des commandes en terminal, ainsi qu’une boucle dans laquelle l’agent observe les résultats et choisit la prochaine étape. Il ne s’agit plus d’autocomplétion ; c’est plutôt une forme de délégation d’une tâche d’ingénierie.

L’IDE en tant que couche d’orchestration

Ce changement modifie la fonction d’une IDE. Autrefois, elle n’était qu’un établi destiné à un seul développeur. À l’heure actuelle, les outils d’intelligence artificielle d’Android Studio offrent des fonctionnalités telles que :

• Mode Agent
• plusieurs conversations d’agents en parallèle
• connexions au serveur MCP
• instructions de niveau projet dans AGENTS.md
• accès à des connaissances spécifiques à Android

recherche sur le Web

compétences spécialisées

Gestion des permissions

validation sur l’émulateur

Google présente Agent Mode comme capable de gérer des tâches de développement en plusieurs étapes, et propose des serveurs MCP ainsi que AGENTS.md comme moyens de l’étendre et de le diriger. L’IDE cesse d’être simplement l’endroit où l’on écrit du Kotlin pour devenir le lieu où l’on exécute et supervise un environnement d’ingénierie assisté par l’intelligence artificielle.

Les fondamentaux sont encore plus importants

Il serait naturel de penser que si des agents écrivent le code, les ingénieurs peuvent en savoir moins. C’est tout le contraire : les agents rendent facile la création rapide d’implémentations erronées, il faut donc des fondamentaux solides pour les détecter.

Kotlin

Il vous faut toujours une maîtrise solide des fonctionnalités du langage qui cachent le plus souvent des bugs subtils :

Flow
StateFlow
SharedFlow
coroutines
structured concurrency
inline functions
sealed classes
value classes
delegation
generics
null safety

L’objectif n’est pas de taper chaque ligne manuellement. Il s’agit plutôt de détecter lorsque le Kotlin généré contient des erreurs subtiles, comme l’utilisation d’un flux chaud là où un flux froid était nécessaire, ou le lancement d’une coroutine en dehors d’un contexte de concurrence structurée.

La plateforme Android

C’est dans le comportement de la plateforme que le code généré semble souvent correct mais échoue en production :

Lifecycle
Process death
Configuration changes
Services
WorkManager
Room
Navigation
Permissions
Storage
Background execution
Notifications
Compose
Views
Performance

Un agent peut générer une classe Worker en quelques secondes. Cela ne dit rien sur le fait que ce worker respecte le cycle de vie de votre application, ni ses exigences en matière de tentatives répétées et de contraintes.

L’architecture comme contraintes pour les agents

Les connaissances en architecture acquièrent une nouvelle finalité. Des modèles tels que MVI et MVVM, l’architecture propre, les limites des modules, les repositories, le DI, la gestion de l’état et la séparation du domaine ne sont pas seulement des moyens d’organiser le code ; ils deviennent les contraintes que l’on transmet à un agent. Au lieu de dire « développer une fonctionnalité », on peut donner des instructions comme suit :

Développez cette fonctionnalité en suivant notre architecture MVI existante. Reprenez les modèles utilisés dans la Fonctionnalité A et la Fonctionnalité B. N’introduisez aucune nouvelle dépendance. Les règles métier doivent se trouver dans la couche de domaine.

Faire référence à des fonctionnalités existantes est particulièrement efficace, car cela oriente l’agent vers des exemples concrets et déjà examinés dans le codebase, plutôt que de se fier à sa notion générale de « MVI ». L’architecture devient alors partie intégrante du langage que l’on utilise pour guider les agents.

Instructions au niveau des repositories avec AGENTS.md

De nombreuses équipes se retrouvent à répéter les mêmes rappels à chaque session : le projet utilise Kotlin et Hilt, la logique métier doit rester en dehors des Composables, l’état est exposé via StateFlow, des conventions de nommage s’appliquent, des tests sont requis, et les fichiers générés sont interdits.

Ces attentes peuvent être intégrées directement dans le répertoire de code. Au moment où cet article est écrit, l’outil Gemini d’Android Studio lit les fichiers AGENTS.md dans lesquels ces préférences sont enregistrées, de sorte que l’agent les perçoit comme faisant partie du contexte du projet. D’autres agents lisent des fichiers similaires ; la même idée est abordée en détail dans un guide pratique pour rédiger un fichier CLAUDE.md efficace.

C’est un petit changement ayant de grandes conséquences. Un répertoire de code contenait traditionnellement :

source code
configuration
tests
documentation

Désormais, il peut également contenir :

AI engineering instructions

La base de code commence à décrire à la fois le logiciel lui-même et la manière dont un agent doit y fonctionner. Traitez ces instructions comme du code : examinez les modifications apportées, gardez-les courtes et précises, et supprimez les règles qui ne s’appliquent plus.

MCP relie l’agent au reste de la chaîne d’outils

Le Model Context Protocol permet aux systèmes d’intelligence artificielle de se connecter à des outils et services externes, ce qui signifie que l’agent n’est plus limité à un panneau de chat. Grâce aux serveurs MCP, il peut potentiellement accéder à :

GitHub
Databases
Design tools
Documentation
Issue trackers
CI systems
Cloud services
Internal APIs

Les outils d’IA d’Android Studio prennent actuellement en charge la connexion à des serveurs MCP, y compris ceux situés à distance. Imaginez une seule demande demandant à l’agent de créer un nouvel écran de profil à partir d’un fichier Figma, de réutiliser les tokens de conception existants, de connecter cet écran à l’endpoint du profil, de gérer les états de chargement et d’échec, d’ajouter des tests et de préparer une demande de fusion. Son exécution implique de nombreux systèmes en même temps :

Developer
    ↓
AI Agent
    ├── Figma
    ├── Codebase
    ├── Documentation
    ├── API
    ├── Tests
    ├── Git
    └── CI

Lorsqu’un outil coordonne des fichiers de conception, du code, de la documentation, des API, des tests, Git et CI, qualifier cela de « générateur de code » est inapproprié. Il s’agit en réalité d’un agent d’ingénierie, et c’est justement son champ d’action qui rend les permissions et les revues essentielles : chaque système connecté est quelque chose que l’agent peut lire ou modifier.

Le piège : dépendant mais pas capable

Cette nouvelle configuration présente un mode de défaillance caractéristique. Un développeur peut devenir dépendant de l’IA sans pour autant en maîtriser les capacités. Il est tout à fait possible de générer du code qui utilise l’ensemble de ces outils :

Flow
StateFlow
SharedFlow
CoroutineScope
SupervisorJob
Channel

sans comprendre ce que chacun d’eux fait. Tout se compile, le travail semble rapide, mais des mois plus tard, la production rencontre une condition de course liée à l’annulation du cycle de vie que personne dans l’équipe ne parvient à expliquer.

L’IA a accéléré la frappe au clavier ; elle n’a pas amélioré les compétences du développeur. C’est pourquoi examiner ce que l’IA a produit devient de plus en plus précieux que la capacité à le générer. Règle pratique pour les équipes : personne ne doit fusionner du code généré qu’il ne peut pas expliquer ligne par ligne lors de l’examen.

Le contexte est le véritable levier

Les agents de codage dépendent fortement du contexte qu’ils reçoivent. La documentation de Cursor, par exemple, décrit un système d’agents en termes de contexte, d’outils, d’instructions et de modèles. Cela suggère une relation multiplicative approximative :

Agent Quality
=
Model
× Context
× Tools
× Instructions
× Verification

C’est la multiplication qui est essentielle. Un modèle performant utilisé avec un contexte médiocre produit du logiciel de mauvaise qualité, car un facteur proche de zéro abaisse fortement le résultat global. Un modèle correct fonctionnant dans un dépôt bien structuré, doté d’une architecture claire, de tests solides, de documents utiles et d’instructions précises, peut obtenir de bien meilleurs résultats. La compétence clé à développer est l’ingénierie du contexte, dont la rédaction des prompts n’est qu’une partie.

Pourquoi l’« ingénierie des prompts » est trop restreinte

La différence est facile à voir côte à côte. Un prompt simple ressemble à ceci :

"Create a login screen."

Une demande élaborée grâce à l’ingénierie du contexte ressemble à ceci :

Here is our architecture.
Here are our design rules.
Here is the API contract.
Here are existing authentication patterns.
Here are the tests.
Here are the project constraints.
Here is the expected behavior.
Now implement the feature and verify it.

La deuxième version remet à l’agent l’architecture, les règles de conception, le contrat API, les modèles d’authentification existants, les tests, les contraintes et le comportement attendu, puis lui demande d’implémenter et de vérifier ces éléments. Cela ressemble beaucoup plus à la manière dont on informerait un nouveau collègue, et l’instruction n’est qu’un des éléments constitutifs. Lorsqu’un agent se comporte mal, il est utile de déterminer quel de ces éléments a manqué ; notre guide sur le débogage des agents IA par couche explique en détail cette démarche de diagnostic.

L’ingénieur conçoit tout le cycle

Le changement le plus important concerne peut-être la répartition des responsabilités. La relation précédente était directe :

Developer → Code

La nouvelle relation passe par plusieurs étapes, et l’ingénieur en est responsable à chaque niveau :

Developer
    ↓
Specification
    ↓
Agent
    ↓
Tools
    ↓
Code
    ↓
Tests
    ↓
Verification

Gérer la boucle signifie savoir quelle instruction une situation exige :

• "Faire-le", lorsque la tâche est bien définie et à faible risque.
• "Planifier d’abord", lorsque le changement concerne plusieurs modules.
• ">Laisser le code de côté pour l’instant et étudier d’abord l’architecture", lorsque l’on a besoin de comprendre avant de modifier quoi que ce soit.
• ">Réproduire le bug", avant d’accepter toute correction.
• ">Arrêter ; votre hypothèse est fausse", lorsque l’agent avance avec certitude dans la mauvaise direction.

Cette dernière intervention peut s’avérer être l’une des compétences les plus précieuses de toutes, et elle dépend entièrement d’une connaissance suffisante de la plateforme pour repérer l’hypothèse erronée.

Ni développeur Android ni ingénieur de prompts

Aucune de ces deux étiquettes ne décrit à elle seule ce rôle. Un développeur Android qui n’écrit que du Kotlin manuellement sera en retard sur le plan de l’efficacité. Celui qui peut demander du Kotlin à une IA mais ne maîtrise pas l’architecture d’Android se retrouvera tôt ou tard bloqué. La combinaison idéale est la suivante :

Android Engineering
        +
AI Agent Skills
        +
System Design
        +
Context Engineering
        +
Verification
        =
AI-Augmented Android Engineer

En pratique, cela signifie entretenir ses connaissances en Android, approfondir sa compréhension de l’architecture, apprendre à communiquer des exigences avec précision aux machines, et s’habituer aux agents, à leurs outils, au MCP, aux instructions de dépôt et aux vérifications automatisées. Surtout, cela signifie savoir reconnaître quand l’IA se trompe. Un agent peut produire avec assurance deux mille lignes de code ; c’est un ingénieur qui doit juger si ces lignes ont leur place.

Le futur le plus réaliste n’est pas l’IA qui remplace les développeurs, mais des développeurs capables de travailler efficacement avec des agents pour remplacer les workflows qui ne le permettent pas. Un ingénieur possédant de solides connaissances de base et une configuration d’agents bien organisée peut potentiellement accomplir ce qui nécessitait autrefois beaucoup plus d’efforts manuels. L’ingénierie ne disparaît pas ; elle passe à un niveau supérieur, où le raisonnement, la définition des contraintes et la validation des résultats comptent plus que les frappes au clavier, et où l’architecture agit comme une carte empêchant les agents de s’égarer.

Points clés

• Considérez les instructions destinées à un agent comme des spécifications : indiquez les technologies, les décisions de performance, les exigences en matière de résilience, les contrats, l’étendue des tests et ce qui ne doit pas changer.
• Vérifiez le code généré en examinant le système qui l’entoure (propriété de l’état, cycle de vie, fin du processus, concurrence, annulation), et non en vérifiant simplement s’il se compile.

Investissez dans les fondamentaux ; ce sont eux qui vous permettent de détecter rapidement des implémentations erronées mais plausibles.

Codez les conventions de l’équipe dans des fichiers d’instructions au niveau du répertoire, tels que AGENTS.md, et prenez-en soin comme du code.

Mieux améliorez les résultats en améliorant le contexte (architecture, tests, documents, exemples), car un facteur faible limite l’ensemble du résultat.

Réservez-vous le rôle de décision : déterminez quand l’agent doit agir, planifier, enquêter, reproduire ou s’arrêter.