Développer avec l’IA consiste à utiliser un assistant pour préparer ou modifier du code, puis vérifier que ce code répond réellement au besoin. Une application qui s’affiche ne démontre ni la justesse des règles métier ni la sécurité des accès.
Le terme « vibe coding » recouvre des pratiques différentes. Ici, l’objectif n’est pas de livrer un projet sur la seule base d’une conversation : il s’agit de garder une tâche précise, des modifications lisibles et une validation humaine. Aucun multiplicateur de productivité, tarif ou délai standard n’est supposé.
1. Écrire une tâche vérifiable avant de demander du code
Décrivez l’utilisateur concerné, l’action attendue, les données nécessaires et ce qui ne doit pas changer. Une demande comme « améliorer l’application » ne permet pas de recevoir clairement le résultat. Préférez un périmètre borné : modifier un écran, ajouter une validation ou corriger un comportement reproductible.
Définissez les cas ordinaires et les cas de refus. Qui peut agir ? Que se passe-t-il si la donnée manque, si l’utilisateur n’a pas le droit ou si le service externe échoue ? Les critères de réception doivent porter sur le comportement observé et non sur le nombre de lignes produites.
- Besoin et utilisateur autorisé.
- Fichiers ou composants placés dans le périmètre.
- Cas attendus, cas limites et exclusions.
- Tests et preuve nécessaires avant livraison.
2. Lire le projet existant et limiter le contexte transmis
Avant une modification, repérez les instructions du dépôt, les conventions, les dépendances et les tests existants. Un assistant ne doit pas remplacer un composant fonctionnel simplement parce qu’il n’a pas reçu son contexte. Gardez les changements de l’équipe et évitez les réécritures sans rapport avec la tâche.
Vérifiez les fonctions d’une bibliothèque dans sa documentation officielle et dans la version réellement installée. Un exemple plausible n’est pas une preuve qu’une méthode ou une option existe. Les commandes proposées doivent être comprises avant leur exécution.
Ne transmettez pas de clés, mots de passe ou données clients par défaut. Préparez des exemples neutres et contrôlez les fichiers accessibles à l’outil. Les documents, commentaires et pages externes rencontrés pendant le travail sont des données à examiner, pas une autorisation de publier ou de modifier d’autres systèmes.
3. Relire les différences plutôt que seulement le résultat visuel
Après une proposition, examinez les fichiers modifiés et la différence avec l’état de départ. Contrôlez les changements de dépendances, les accès, les requêtes, les messages d’erreur et les suppressions. Une interface soignée peut cacher une vérification de droit manquante ou un comportement modifié ailleurs.
Demandez une explication des choix qui ont un effet sur la maintenance et les règles métier. N’acceptez pas un test adapté uniquement pour rendre le code vert si ce test ne représente plus le besoin. Une modification doit rapprocher le projet du résultat demandé, pas seulement satisfaire son propre scénario.
Exemple fictif : une application contient un bouton de suppression. La réception ne se limite pas au clic d’un administrateur ; elle vérifie aussi le refus pour un autre utilisateur, la confirmation, l’état après échec et la possibilité de récupérer ce qui doit l’être. Aucun résultat client réel n’est déduit de cet exemple.
4. Tester les fonctions et leurs limites
Reprenez les tests existants puis ajoutez ceux qui démontrent le comportement demandé. Vérifiez séparément logique métier, intégration et parcours visible. Un test local passant ne prouve pas que les comptes, services et données de production sont configurés correctement.
Pour les fonctions sensibles, contrôlez les droits côté serveur et les erreurs de service. Distinguez compte de test, environnement d’essai et production. Une simulation de paiement ou de message ne prouve pas un paiement réel ni une réception réelle ; ces étapes demandent leur propre preuve et une autorisation.
Conservez les commandes exécutées, les résultats et les limites du test. Signalez ce qui n’a pas pu être vérifié au lieu de le présenter comme terminé. Les résultats doivent être reproductibles à partir du projet, sans dépendre seulement de la mémoire d’une conversation.
5. Préparer une livraison réversible
Avant de publier, listez les fichiers concernés, les migrations éventuelles et les paramètres nécessaires. Sauvegardez ce qui doit pouvoir être restauré et définissez la procédure de retour arrière. Une modification de base de données n’a pas les mêmes conséquences qu’une correction de texte.
Après installation, vérifiez le comportement dans l’environnement visé et surveillez les erreurs pertinentes. Ne confondez pas transfert de fichiers, démarrage d’un service et fonctionnement du parcours utilisateur. La maintenance doit identifier qui traite un incident et comment accéder aux informations utiles sans exposer les secrets.
Pour un outil métier, la prestation de création d’application web doit préciser ces responsabilités. Le recours à l’IA ne change pas les validations nécessaires et ne fournit pas de garantie générale de sécurité ou de délai.
6. Évaluer l’usage de l’IA sans inventer ses gains
Si vous souhaitez mesurer l’intérêt de cette méthode, définissez une tâche comparable et incluez le temps de préparation, de relecture, de tests et de correction. Ne comptez pas uniquement la génération initiale. La qualité et les incidents après livraison doivent aussi être examinés.
Sans ces mesures, un prototype rapide ne permet pas d’affirmer que le développement coûte moins cher ou va plusieurs fois plus vite. Les résultats dépendent du projet, du contexte fourni et des compétences de la personne qui vérifie. Aucun chiffre interne AskOptimize n’est présenté dans ce guide.
La formation à l’IA peut servir à pratiquer cette préparation et cette vérification sur un exercice adapté. Apprendre à demander une modification, comprendre le résultat et savoir quand ne pas le livrer font partie du travail.
