Comment travailler avec un développeur sur une application créée par IA

Pour bien travailler avec un développeur sur une application créée avec l'IA, donnez-lui le code dans un dépôt Git, une synthèse d'une page sur ce que fait l'application et pourquoi, et une tâche clairement définie avec une définition de « terminé ». Convenez de qui modifie quelles parties pour que vous et l'IA n'écrasiez pas son travail, gardez le dépôt et les comptes d'hébergement à votre nom, et partagez les secrets via les paramètres appropriés plutôt que par messages.

Nombreux sont ceux qui construisent la première version d'une application avec l'IA, puis font appel à un développeur : pour ajouter les paiements, corriger quelque chose que l'IA n'arrive pas à bien faire, revoir la sécurité ou reprendre le projet à mesure qu'il grandit. Si vous hésitez encore à embaucher, voir embaucher un développeur ou construire avec l'IA. Ce guide suppose que vous avez décidé, et qu'il veut que la collaboration se passe bien.

Quand un développeur en vaut la peine

Les raisons courantes de faire appel à quelqu'un :

• Un problème que l'IA n'arrive pas à résoudre après plusieurs tentatives claires et retours en arrière.
• Des zones à risque : paiements, autorisations, données sensibles, migrations de base de données.
• Une revue de sécurité ou de code avant le lancement ou avant d'accueillir des clients plus importants.
• Les performances une fois le trafic réel arrivé.
• La croissance : l'application est devenue une entreprise et a besoin de quelqu'un qui en soit responsable.

Bien identifier la raison oriente tout le reste.

Étape 1 : mettre le code dans un endroit partageable

Les développeurs travaillent à partir de dépôts Git. Avant de contacter qui que ce soit :

1. Reliez le projet à un dépôt GitHub privé (ou similaire), ou exportez-le.
2. Assurez-vous qu'aucun secret ne figure dans le code ni dans l'historique. Voir comment protéger vos clés d'API.
3. Vérifiez que le projet se lance à partir d'une copie fraîche : demandez à l'IA d'écrire les étapes d'installation.

Rédige un README pour un développeur qui rejoint ce projet : ce que fait l'application, la stack, comment l'installer et la lancer en local, les variables d'environnement nécessaires (noms uniquement), la structure des dossiers et tout ce qui est fragile ou inhabituel.

Si Git vous est nouveau, comment utiliser Git avec une application créée par IA présente les bases.

Étape 2 : rédiger une synthèse d'une page

Le développeur n'a pas lu votre historique de discussion. Donnez-lui le contexte en une page :

• Ce que fait l'application, pour qui, et combien de personnes l'utilisent.
• Ce qui compte le plus : les parcours qui ne doivent jamais tomber en panne.
• Les problèmes connus et ce que vous avez déjà essayé.
• La tâche, et la façon dont vous saurez qu'elle est terminée.
• Les contraintes : budget, délai, éléments qu'il ne doit pas modifier.

Une bonne « définition de terminé » est vérifiable : « Un utilisateur connecté peut souscrire à un abonnement mensuel avec Stripe Checkout, le plan apparaît sur sa page de compte, et la résiliation depuis le portail client le fait repasser en gratuit à la fin de la période. » Et non « régler les paiements ».

Étape 3 : donner l'accès en toute sécurité

• Code : ajoutez-le comme collaborateur du dépôt. N'échangez pas de fichiers ZIP une fois le travail commencé.
• Générateur : si votre générateur d'applications IA gère les membres d'équipe, invitez-le dans un espace de travail qui ne contient que ce projet.
• Secrets : ajoutez-les dans les paramètres de votre hébergeur, ou partagez-les via un gestionnaire de mots de passe. Ne collez jamais de clés dans un e-mail ou un chat.
• Comptes de test : créez-les avec des données de test, plutôt que de partager votre propre connexion.
• Données de production : uniquement s'il en a vraiment besoin, et seulement ce dont il a besoin.

Gardez le dépôt, le domaine et les comptes d'hébergement à votre nom. Ajoutez des personnes ; ne transmettez pas vos comptes.

Étape 4 : convenir de qui modifie quoi

La principale source de friction, c'est que deux parties, vous avec une IA et le développeur, modifient le même code en même temps. Choisissez une règle :

Quelle que soit l'option choisie : faites un pull du dernier code avant chaque session de formulation de demandes, et réalisez les grosses modifications sur des branches que l'autre personne pourra relire.

Étape 5 : communiquer par écrit

• Décrivez les problèmes avec les étapes, le résultat attendu et le résultat obtenu. Voir comment rédiger un bon rapport de bug.
• Centralisez les décisions en un seul endroit : un outil de suivi de tickets, un document partagé ou les commentaires des pull requests.
• Demandez-lui d'expliquer les modifications en langage simple dans chaque pull request.
• Convenez de la fréquence des points d'étape.

Étape 6 : relire son travail

Vous n'avez pas besoin de lire le code pour vérifier le travail. Contrôlez :

• Qu'il fait ce que disait la synthèse, sur l'aperçu ou la copie de préproduction.
• Que rien d'autre n'est cassé : testez vos parcours critiques.
• Qu'il a expliqué ce qu'il a modifié et pourquoi.
• Qu'aucun secret n'est apparu dans le code.

Pour une relecture plus poussée, comment relire le code généré par IA propose une liste de contrôle qui s'applique aussi au code écrit par un humain. Vous pouvez aussi demander à votre générateur IA de vous expliquer, en termes simples, une pull request du développeur.

Étape 7 : garder la propriété claire

• Le dépôt, l'hébergement, le domaine et les comptes tiers restent à votre nom.
• Formalisez par écrit la propriété du code qu'il écrit avant le début du travail. Consultez les règles locales ou un conseiller pour les questions contractuelles.
• À la fin du travail, retirez son accès et régénérez les clés qu'il a pu voir.

Exemples de demandes

Un développeur a modifié le code de la commande dans la dernière pull request. Explique en langage simple ce qu'il a changé et si d'autres parties de l'application en dépendent.

Liste les parties de cette application les plus complexes ou les plus risquées, pour que je puisse indiquer à un développeur où concentrer sa relecture.

Je confie les paiements à un développeur. Désormais, ne touche à aucun fichier sous src/payments ni aux routes /api/billing. Si une modification nécessite de les toucher, dis-le-moi plutôt que de la faire.

Erreurs courantes

• Pas de synthèse. Le développeur passe des heures payées à deviner ce que vous vouliez.
• Un périmètre flou comme « corriger les bugs » ou « rendre l'app prête pour la production ».
• Modifier en même temps sans faire de pull, puis perdre du travail à cause des conflits.
• Partager votre propre connexion ou coller des clés dans le chat.
• Des comptes au nom du développeur, ce qui rend la séparation difficile.
• Oublier de retirer l'accès et de régénérer les clés après la mission.

Liste de vérification

• Le code est dans un dépôt privé à mon nom, sans secret.
• Un README explique l'installation ; une synthèse d'une page explique l'application et la tâche.
• La tâche a une définition de « terminé » vérifiable.
• L'accès se fait par invitation de collaborateur, et les secrets via les paramètres ou un gestionnaire de mots de passe.
• Nous avons convenu de qui modifie quoi, et je fais un pull avant de formuler une demande.
• Le travail est relu par rapport à la synthèse et aux parcours critiques.
• La propriété est formalisée par écrit ; l'accès est retiré et les clés régénérées à la fin du travail.

Travailler avec un développeur sur Mythex

• Invitez-le dans un espace de travail. Les propriétaires peuvent inviter un nombre illimité de collaborateurs, sans frais par siège ; les membres travaillent sur les projets de l'espace. Utilisez un espace séparé pour qu'il ne voie que ce projet. Les crédits des applications publiées sont facturés au propriétaire de l'espace. Voir Invitations.
• Synchronisation GitHub et export (Pro). Reliez un dépôt et poussez/tirez les modifications, ou exportez le projet sans les secrets. Voir GitHub, export et import.
• Partagez un lien d'aperçu pour montrer un travail en cours à quelqu'un qui n'a pas de compte Mythex ; supprimez-le une fois terminé.
• Le mode Question répond à des questions sur le code sans le modifier : pratique pour comprendre les changements d'un développeur.

Si le développeur fera tourner l'application ailleurs, voir comment exporter et auto-héberger une application créée par IA.

Questions