Les pratiques décrites correspondent au contexte du DDLP Lab ; elles ne constituent pas une recommandation générale ni une promesse sur les offres, les modèles ou les quotas.
Pourquoi on s’en sert
Ces outils évitent de partir d’une page blanche et permettent de faire progresser une idée jusqu’à son implémentation.
ChatGPT sert à déposer une pensée encore brute, notamment à l’oral, puis à la structurer par itérations. Il accompagne la réflexion, la stratégie, l’exploration et la rédaction des premières spécifications fonctionnelles.
Les GPT personnalisés prennent en charge des tâches répétitives qui demandent du raisonnement sans justifier une automatisation par le code : conduire une interview, préparer une fiche structurée ou appliquer une méthode stable.
Codex et Cursor interviennent ensuite sur les tâches de développement. Dans le workflow décrit ici, Codex aide davantage à affiner les spécifications et à préparer une architecture, tandis que Cursor prend généralement le relais pour travailler directement dans la base de code.
Les quatre briques du workflow
ChatGPT
Dans le contexte du Lab, ChatGPT est principalement utilisé comme partenaire de réflexion. L’utilisateur peut énoncer librement ses idées, demander une reformulation, un plan, une comparaison ou une première spécification, puis ajouter progressivement les contraintes nécessaires.
L’application desktop ChatGPT regroupe aujourd’hui les expériences Chat, Work et Codex. Chat sert aux échanges rapides, Work aux tâches longues et aux livrables, et Codex au travail de développement ; les disponibilités dépendent du compte et de l’espace de travail utilisés.
GPT personnalisés
Un GPT personnalisé est une version de ChatGPT configurée avec des instructions, des connaissances et des capacités spécifiques. Il sert ici à appliquer une méthode stable à des demandes dont le résultat n’est pas entièrement déterministe.
Le GPT peut poser des questions successives, interpréter les réponses et produire un format défini à l’avance, comme une fiche ressource prête à relire. La création et la modification des GPT s’effectuent dans l’interface Web de ChatGPT ; leur utilisation reste soumise aux capacités et permissions du compte.
Codex
Codex est l’agent de développement d’OpenAI. Il peut travailler avec des dossiers locaux, des dépôts, un terminal et des outils de développement, puis écrire ou modifier du code, lancer des commandes et exécuter des tests.
Dans le workflow du Lab, il est mobilisé pour préciser une spécification,
transformer cette spécification en contraintes techniques, proposer une
architecture de départ et, lorsque c’est pertinent, réaliser une tâche de code
de bout en bout. Des fichiers comme AGENTS.md et des skills transmettent les
règles et procédures réutilisables.
Cursor
Cursor est un environnement de développement intégrant plusieurs modèles d’IA et un agent capable d’explorer et de modifier une base de code.
Dans l’usage décrit ici, les modes permettent de séparer l’exploration, la planification et l’implémentation : Ask sert à questionner le projet, Plan à préparer une stratégie et Agent à modifier les fichiers et exécuter les commandes. Le choix du mode et du modèle dépend du risque et de la nature de la tâche.
Ce qu’il faut vérifier avant usage
Les abonnements, modèles accessibles, quotas, crédits inclus et règles de facturation peuvent évoluer. Ils doivent être contrôlés sur les pages tarifaires officielles avant toute décision d’achat ou estimation de capacité.
Le contrôle des données doit être configuré explicitement. Les prompts, extraits de code et contextes nécessaires aux fonctions d’IA peuvent être transmis aux services concernés selon les réglages actifs. Travailler sur un dossier local ou dans un environnement Google Workspace contrôlé ne garantit pas à lui seul que les données restent dans cet environnement.
Les conditions d’accès, les permissions locales, l’accès réseau et les limites d’utilisation doivent être vérifiés dans les comptes réellement utilisés au DDLP Lab.
Limites à garder en tête
Les outils peuvent produire des résultats plausibles mais incorrects, incomplets ou incompatibles avec le projet. Une spécification issue d’un échange oral doit être relue avant de devenir une référence.
Le code généré ne doit pas être accepté sur la seule base d’un examen visuel. Les garde-fous utiles sont la documentation des règles du projet, des critères d’acceptation vérifiables, des tests automatisés, des permissions limitées, un environnement isolé et un déploiement progressif avec retour arrière possible.
Une commande autorisée peut modifier des fichiers, installer des dépendances, accéder au réseau ou produire d’autres effets sur l’environnement. Les autorisations doivent donc être adaptées au risque de chaque tâche.
Sources officielles :