Construire son appli avec l'IA : ce qui marche, ce qui casse, et quand appeler quelqu'un

Un fondateur m'a montré l'outil qu'il avait construit en un week-end avec un assistant de code. Un vrai outil, utilisé par son équipe tous les jours, pour un problème qu'aucun logiciel du marché ne résolvait. Il y a trois ans, ça aurait coûté un développeur pendant deux mois. C'est une excellente nouvelle, et je ne vais pas la relativiser.

La question qu'il m'a posée ensuite est la bonne : « Est-ce que je peux lui faire confiance ? »

Ce qui marche vraiment

Les outils actuels sont très bons pour produire une première version qui fonctionne. Interface, formulaires, base de données, connexion à un service tiers : tout ça sort propre en quelques heures. Pour un outil interne utilisé par cinq personnes, c'est souvent largement suffisant, et c'est une erreur de le refaire « proprement » pour le principe.

Le piège n'est pas la qualité du code ligne par ligne. Le piège, c'est ce que l'assistant ne vous dit pas parce que vous ne lui avez pas demandé.

Les cinq endroits où ça casse

Les accès. C'est le numéro un, et de loin. L'appli a-t-elle une vraie notion de qui a le droit de voir quoi ? Très souvent, l'assistant a mis un écran de connexion, et derrière, n'importe quel utilisateur connecté peut tout lire ou tout modifier s'il connaît l'adresse. Tant que c'est votre équipe, personne ne le remarque. Le jour où vous ouvrez à un client ou un partenaire, c'est une fuite de données.

Les clés et mots de passe. Les clés d'API et les identifiants de base de données se retrouvent facilement dans le code lui-même, ou dans un fichier envoyé sur GitHub. Si le dépôt est public, ou l'a été cinq minutes, considérez-les comme compromis.

Les données. Pas de sauvegarde, pas de contraintes dans la base, pas de validation de ce qu'on y écrit. L'appli marche jusqu'au jour où quelqu'un tape une date au mauvais format, ou efface une ligne dont tout le reste dépendait. Le mal est souvent déjà fait quand on s'en rend compte.

La dépendance à l'outil qui l'a généré. Certaines plateformes hébergent votre appli chez elles et rendent la sortie compliquée. Ce n'est pas un problème tant que vous êtes content. Ça en devient un le jour où le prix change ou le service ferme. Sachez où est votre code, et vérifiez que vous pouvez le faire tourner ailleurs.

Les coûts qui dérivent. Un appel à un modèle d'IA par action utilisateur, sans limite ni cache, c'est une facture qui suit l'usage. Bien pour un prototype, moins bien quand l'équipe l'adopte vraiment.

Ce que je fais quand on m'appelle

Je ne réécris pas. Dans neuf cas sur dix, l'appli mérite de vivre. Je lis le code avec les cinq points ci-dessus en tête, je note ce qui est urgent, ce qui peut attendre, et ce qui est très bien comme ça. Puis je corrige l'urgent, en général en une journée ou deux : les accès, les secrets, une sauvegarde automatique. Le reste va dans une liste que vous gardez.

Et je vous montre comment continuer à faire évoluer l'outil vous-même, avec des règles données à votre assistant pour qu'il ne refasse pas les mêmes erreurs. C'est la partie qui a le plus de valeur : vous repartez plus autonome, pas plus dépendant.

Quand appeler quelqu'un

Pas tout de suite. Si c'est un outil interne pour trois personnes, avec des données qui ne sont pas sensibles, continuez. Appelez quand l'une de ces choses devient vraie : des gens extérieurs à l'équipe vont s'y connecter, des données clients ou financières y vivent, ou l'équipe ne pourrait plus travailler sans. À ce moment-là, une journée de revue coûte beaucoup moins cher que la première fuite ou la première perte de données.

Si vous en êtes là, c'est exactement ce que je fais avec la mise en production d'une appli faite avec l'IA : un environnement de test, des sauvegardes vérifiées, des tests sur ce qui vous fait gagner de l'argent, et je ne vous dirai pas de tout réécrire.