Parent : [[INDEX-IA]]

IA Productivité — Prompts, debug, vérification, tâches dangereuses

Pattern — Formuler un prompt pour du code directement utilisable (CSCF)

Problème : Un prompt vague produit du code illustratif non utilisable directement, avec des placeholders et des hypothèses non déclarées.

Solution : Format CSCF : Contexte (stack exact, version, fichiers concernés), Spécification (comportement attendu en entrée/sortie), Contraintes (ce qu'il ne faut pas faire), Format (signature de fonction, style de code existant). Plus le contexte est précis, moins les itérations nécessaires.

Exemple : "En Python 3.11 avec FastAPI 0.104, dans routes/users.py, créer un endpoint POST /users/bulk qui reçoit une liste de UserCreate (défini dans schemas.py), insère en batch avec SQLAlchemy async, retourne les IDs créés. Même style que create_user existant."

Pattern — Débugger avec une IA sans tout donner : isoler le signal

Problème : Coller l'intégralité d'un fichier de 500 lignes noie l'IA dans du contexte non pertinent et dégrade la qualité de l'analyse.

Solution : Extraire uniquement : (1) la stacktrace complète ou le symptôme exact, (2) la fonction incriminée ± 20 lignes de contexte, (3) les types des données en entrée, (4) ce que vous attendiez vs ce qui se passe.

Exemple : Au lieu de coller models.py entier → "TypeError: 'NoneType' is not subscriptable à la ligne 47. Voici la fonction : [15 lignes]. user est censé être un dict mais semble être None."

❌ Code IA inutilisable : contexte non fourni

Problème : Une IA qui génère un exemple générique non connecté à votre codebase produit un code qui doit être réécrit avant utilisation.

Solution : Toujours fournir la signature des fonctions/types existants que le nouveau code doit utiliser. Si vous avez un pattern établi, en montrer un exemple. L'IA reproduit le pattern fourni — si vous n'en fournissez pas, elle invente le sien.

Exemple : Fournir class UserRepository existant + sa méthode find_by_id → l'IA génère le nouveau code avec la même signature et le même style.

Pattern — Vérifier une réponse d'IA rapidement : cibler les zones d'hallucination

Problème : Vérifier intégralement une réponse d'IA prend autant de temps que de l'écrire soi-même.

Solution : Vérification ciblée sur les zones à risque élevé : (1) noms de fonctions/méthodes d'API, (2) numéros de version et paramètres optionnels, (3) comportement des cas limites. Faire confiance à la structure logique globale, vérifier les détails concrets.

Exemple : Code avec pandas.DataFrame.to_parquet(engine='pyarrow', compression='gzip', row_group_size=1000) → vérifier que row_group_size existe réellement. Les paramètres obscurs sont le point de défaillance #1.

❌ Tâches dangereuses à déléguer sans vérification : migrations et scripts destructifs

Problème : Un script de migration généré par une IA et exécuté sans relecture peut détruire des données de prod de manière irréversible.

Solution : Règle absolue : tout script avec DELETE, DROP, UPDATE sans WHERE strict, ou migration de schéma doit être relu ligne par ligne avant exécution. Toujours tester sur un dump de prod en local avant. Jamais d'exécution directe en prod sur la confiance dans l'IA.

Exemple : "Supprime les users inactifs depuis 2 ans" → l'IA génère DELETE FROM users WHERE last_login < NOW() - INTERVAL '2 years' sans vérifier si last_login est NULL pour les nouveaux comptes → suppression de tous les nouveaux inscrits.

❌ Itérer en conversation quand le contexte initial est mauvais

Problème : Continuer à corriger quand le contexte initial était mauvais accumule des corrections partielles et produit du code incohérent.

Solution : Si après 2 itérations la réponse s'éloigne de la cible, ne pas continuer à corriger — recommencer avec un prompt refactoré intégrant les erreurs observées. Itérer en conversation fonctionne pour les ajustements mineurs (< 20% du code). Pour des changements de direction → nouveau prompt.

Exemple : IA génère une solution avec le mauvais pattern après 3 corrections → nouveau prompt avec la contrainte explicite > 4ème correction.

Pattern — Utiliser l'IA pour détecter les cas limites non anticipés

Problème : Écrire des tests soi-même couvre les cas limites anticipés — ceux non anticipés sont précisément ceux qui cassent en prod.

Solution : Après avoir écrit une fonction, soumettre sa signature + comportement attendu avec : "Quels sont tous les cas limites et inputs inattendus qui pourraient casser cette fonction ?" Utiliser la liste comme base de test.

Exemple : Fonction parseDate(str) → l'IA liste : string vide, null, format ISO vs FR vs US, timezone implicite, 29 février année non-bissextile, "undefined" en string. La moitié n'aurait pas été testée manuellement.

❌ Faire confiance à l'IA sur les domaines réglementaires

Problème : Une IA génère des réponses fluides et confiantes sur la conformité RGPD, la cryptographie réglementaire — qui peuvent être partiellement fausses et engager la responsabilité.

Solution : Les domaines où l'erreur a des conséquences légales (RGPD, PCI-DSS, HIPAA, droit du travail) nécessitent une validation humaine experte. Utiliser l'IA pour la structure et les questions à poser — pas pour les réponses finales.

Exemple : "Est-ce que mon implémentation est RGPD-compliant ?" → la vraie réponse dépend du contexte de traitement, de la finalité, des contrats DPA — non inférables depuis le code.

Pattern — Décomposer une tâche complexe avant de la donner à l'IA

Problème : Donner une tâche grande et vague produit une réponse grande et vague — ou une implémentation qui fait des choix non souhaités.

Solution : Décomposer soi-même en sous-tâches de 30-60 minutes avant de prompter. Donner une sous-tâche à la fois avec le contexte de la tâche parente. Vérifier et intégrer avant la suivante.

Exemple : "Crée-moi tout le système d'auth" → mauvais. "Crée la fonction hashPassword(plaintext) → hash en bcrypt avec salt 12 rounds, avec son test unitaire" → utilisable directement.

Pattern — Utiliser l'IA comme rubber duck structuré

Problème : Rester bloqué sur un problème de conception sans interlocuteur technique ralentit la décision et génère du overthinking.

Solution : Présenter le problème en forçant l'explicitation : "Voici mon problème, voici les 2 approches que j'envisage, voici ce qui me bloque sur chacune." L'acte de formuler débloque souvent seul. Ce n'est pas chercher la bonne réponse — c'est forcer la clarté du problème.

Exemple : "J'hésite entre X et Y. X pose le problème A. Y pose le problème B. Mon vrai besoin est Z." → l'IA identifie souvent que le vrai problème est C, non mentionné, qui invalide les deux options.