Les bonnes pratiques pour Claude Code

Claude Code s’est imposé en 2025 et 2026 comme l’un des outils de développement assisté par IA les plus puissants et les plus adoptés du marché. Cet assistant de programmation natif du terminal développé par Anthropic comprend la structure de votre projet, écrit du vrai code sur votre machine et automatise des tâches qui prenaient autrefois des heures. Depuis sa disponibilité générale en mai 2025, Claude Code est devenu l’un des outils de développement IA les plus largement adoptés, contribuant à ce qu’Anthropic atteigne plus d’un milliard de dollars de revenus annualisés en novembre 2025.

Pourtant, entre les développeurs qui obtiennent des résultats spectaculaires et ceux qui peinent à dépasser le stade du gadget utile, la différence ne tient pas à la puissance du modèle. Elle tient à la façon dont on l’utilise. Sans bonnes pratiques, vous obtenez du code moyen, des sessions qui partent dans tous les sens, et des résultats incohérents. Avec les bonnes pratiques, vous obtenez un assistant qui comprend votre projet, respecte vos conventions, et produit du code de qualité professionnelle à chaque session.

La bonne nouvelle est que ces pratiques sont accessibles et rapidement intégrables dans votre workflow quotidien. Les trois pratiques les plus impactantes pour améliorer votre productivité avec Claude Code sont : configurer un fichier CLAUDE.md avec vos conventions projet, structurer vos prompts avec un contexte précis, et exploiter le mode plan avant chaque tâche complexe. Ces fondamentaux, combinés à une gestion rigoureuse du contexte et à une utilisation intelligente des commandes slash, transforment Claude Code d’un assistant occasionnel en véritable partenaire de développement.

Dans cet article, nous vous présentons les bonnes pratiques essentielles pour tirer le meilleur parti de Claude Code en 2026 de la configuration initiale à la gestion des sessions longues, en passant par le prompting structuré et l’intégration Git.

Configurer son fichier CLAUDE.md : la base de tout

Si vous ne deviez adopter qu’une seule bonne pratique pour transformer votre utilisation de Claude Code, ce serait celle-ci. Le fichier CLAUDE.md est la fondation sur laquelle repose l’ensemble de votre expérience avec l’outil. C’est le premier fichier que Claude Code lit à chaque session — et son contenu conditionne directement la qualité, la cohérence et la pertinence de tout ce que Claude va produire pour vous.

Le fichier CLAUDE.md est la fondation de tout. C’est le premier fichier que Claude Code lit à chaque session. Si votre CLAUDE.md est vide ou mal structuré, Claude Code travaille à l’aveugle. S’il est bien fait, Claude Code comprend votre projet comme un développeur senior qui connaît la codebase. Meydeey Cette métaphore du développeur senior est particulièrement juste — un CLAUDE.md bien construit permet à Claude Code de prendre des décisions cohérentes avec votre architecture, vos conventions et vos contraintes, sans que vous ayez à les répéter à chaque session.

La première information indispensable à inclure dans votre CLAUDE.md est le stack technique de votre projet. Claude Code doit savoir précisément avec quels frameworks, langages, bibliothèques et outils vous travaillez. Claude Code doit savoir comment builder, tester et lancer votre projet. Sans cette information, il devine — et il se trompe. Meydeey Indiquez vos commandes de développement, de build et de test — par exemple npm run dev pour le serveur de développement et npm run build pour la production. Ces informations semblent basiques, mais leur absence oblige Claude à faire des hypothèses qui génèrent des erreurs et des itérations inutiles.

La deuxième section essentielle concerne vos conventions de code. C’est ici que vous définissez la façon dont Claude doit écrire avec vous. Nommage des variables, structure des fichiers, patterns à suivre, patterns à éviter. Tout ce qui n’est pas dans le CLAUDE.md est laissé à l’appréciation de Claude Code et ses choix ne seront pas toujours les vôtres. Précisez si vous utilisez TypeScript strict sans any, si vous préférez les fonctions courtes à responsabilité unique, si vous imposez une gestion d’erreur systématique. Ces règles de style évitent les refactorisations coûteuses et garantissent une cohérence du code sur toute la durée du projet.

La troisième section à ne pas négliger est celle des règles comportementales. Au-delà de ce que Claude doit coder, vous devez définir comment il doit se comporter. Précisez les règles comportementales essentielles : mode autonomie, ne jamais refactorer sans demande explicite, ne jamais commiter automatiquement, toujours lancer le build avant de dire que c’est fait, clarifier plutôt que supposer en cas d’ambiguïté technique. Ces garde-fous comportementaux évitent les mauvaises surprises notamment les modifications non sollicitées de fichiers critiques ou les commits automatiques dans des branches sensibles.

Pour les projets complexes, quand votre CLAUDE.md devient trop chargé, découpez les instructions dans des fichiers dédiés dans le dossier .claude/rules/. Chaque fichier reste focalisé et facile à maintenir. Vous pouvez même utiliser le path scoping en ajoutant un bloc YAML frontmatter à un fichier de règle, il ne s’active que lorsque Claude travaille dans les répertoires correspondants. Un fichier de conventions API ne se chargera pas quand Claude édite un composant React. Le contexte reste léger et les règles restent pertinentes.

Enfin, une règle de taille s’impose : conservez votre CLAUDE.md sous 200 lignes. Les fichiers plus longs consomment trop de contexte et l’adhérence aux instructions se dégrade sensiblement au-delà de ce seuil. La concision n’est pas une contrainte stylistique c’est une contrainte technique directement liée à la fenêtre de contexte de Claude. Un CLAUDE.md dense de 50 lignes bien choisies sera toujours plus efficace qu’un document exhaustif de 500 lignes dont la moitié n’est plus prise en compte en fin de session.

Gérer la fenêtre de contexte : la ressource la plus précieuse

Si le fichier CLAUDE.md est la fondation de votre configuration, la fenêtre de contexte est la ressource la plus critique à gérer pendant l’utilisation de Claude Code. C’est elle qui détermine la qualité de vos échanges au fil du temps et c’est sa mauvaise gestion qui explique la plupart des dégradations de performance que les développeurs attribuent à tort au modèle lui-même.

Commençons par comprendre précisément ce qu’est la fenêtre de contexte. La fenêtre de contexte de Claude contient l’intégralité de votre conversation, y compris chaque message, chaque fichier que Claude lit et chaque sortie de commande. Cela peut se remplir rapidement. Une seule session de débogage ou exploration de base de code peut générer et consommer des dizaines de milliers de tokens. Les performances des LLM se dégradent à mesure que le contexte se remplit. Lorsque la fenêtre de contexte est presque pleine, Claude peut commencer à oublier les instructions antérieures ou faire plus d’erreurs. Ce phénomène n’est pas un bug c’est une limitation architecturale fondamentale que toute bonne pratique d’utilisation de Claude Code doit prendre en compte.

La première stratégie de gestion du contexte est de découper vos tâches en sous-tâches atomiques. Découpez les tâches volumineuses en sous-tâches atomiques de 5 à 10 minutes. Cette approche présente un double avantage : elle préserve le contexte disponible en limitant le volume d’informations traitées dans une seule session, et elle améliore la qualité des résultats en forçant Claude à se concentrer sur un périmètre précis plutôt que de jongler avec des dizaines de fichiers simultanément. Une tâche bien délimitée produit un code mieux ciblé, plus facile à réviser et à valider.

La deuxième stratégie est l’utilisation proactive des commandes de gestion de contexte intégrées à Claude Code. La commande /compact compresse le contexte quand la conversation devient longue. La commande /clear réinitialise complètement la session. Esc + Esc ou /rewind permet d’ouvrir le menu de rembobinage et de restaurer la conversation et l’état du code précédents, ou de résumer à partir d’un message sélectionné. Ces commandes ne sont pas des solutions de dernier recours elles font partie du workflow normal d’un utilisateur avancé de Claude Code. Intégrez /compact régulièrement dès que vous sentez que la session s’alourdit, sans attendre que les performances se dégradent.

Troisième bonne pratique essentielle : réinitialiser le contexte entre les tâches non liées. Utilisez /clear pour réinitialiser le contexte entre les tâches non liées. Les sessions longues avec un contexte non pertinent peuvent réduire les performances. C’est une erreur fréquente chez les développeurs qui débutent avec Claude Code : ils continuent une session commencée sur une fonctionnalité A pour attaquer une fonctionnalité B complètement différente. Le contexte accumulé sur la fonctionnalité A ne fait que parasiter le travail sur B un /clear net est toujours plus efficace qu’une session surchargée.

Quatrième dimension à maîtriser : la structure de vos fichiers. La taille et la clarté de vos fichiers de code impactent directement la consommation de contexte. Les fichiers de 500 lignes et plus sont un problème pour Claude Code. Il doit lire tout le fichier pour comprendre le contexte, ce qui consomme votre fenêtre de contexte inutilement. Découpez vos fichiers en unités logiques de 100 à 200 lignes maximum. Quand Claude Code travaille sur un fichier court et focalisé, il fait moins d’erreurs, modifie exactement ce qu’il faut et ne touche pas au reste.

Cinquième levier souvent sous-estimé : le nommage explicite de vos fichiers. Claude Code utilise les noms de fichiers pour comprendre leur contenu avant même de les lire. Des noms vagues comme utils.ts ou helpers.js ne lui donnent aucune information. Des noms précis comme format-date.ts ou auth-service.ts permettent à Claude de cibler immédiatement les bons fichiers sans avoir à lire des dizaines de fichiers inutilement. Ce simple réflexe de nommage réduit considérablement la consommation de tokens de découverte et améliore la précision des modifications apportées par Claude.

Structurer ses prompts pour obtenir des résultats professionnels

La qualité de ce que Claude Code produit est directement proportionnelle à la qualité de ce que vous lui demandez. C’est la règle fondamentale que tous les utilisateurs avancés de Claude Code ont intégrée et c’est celle qui fait la différence entre un assistant qui génère du code approximatif et un partenaire qui produit du code de qualité production dès les premières itérations.

La leçon la plus importante est celle-ci : la qualité de vos entrées dictera la qualité de votre résultat. Les capacités de Claude ont franchi un seuil où les problèmes de qualité remontent aux instructions humaines, pas aux limitations du modèle. Autrement dit, si Claude Code produit des résultats décevants, la première question à se poser n’est pas « est-ce que le modèle est assez bon ? » c’est « est-ce que mon prompt est assez précis ? »

La première règle du prompting efficace avec Claude Code est de toujours fournir le contexte avant la demande. Avant de spécifier ce que vous voulez, expliquez dans quel environnement vous travaillez, quelles contraintes s’appliquent et quel est l’objectif final. Un prompt qui commence par « Ajoute une fonctionnalité d’authentification » est infiniment moins efficace qu’un prompt qui commence par « Dans notre application Next.js 15 avec App Router, Supabase Auth et shadcn/ui, ajoute une fonctionnalité d’authentification OAuth2 avec Google qui respecte notre pattern de gestion d’erreur défini dans auth-service.ts. » Structurez vos prompts avec contexte, intention et format de sortie attendu. Ces trois éléments contexte, intention, format sont le squelette de tout prompt professionnel.

La deuxième règle est d’activer le mode plan avant chaque tâche complexe. Activez le mode plan avant chaque tâche complexe impliquant plus de 3 fichiers. Le mode plan force Claude à décrire sa stratégie d’implémentation avant de toucher au code — ce qui vous permet de valider l’approche, d’identifier les problèmes potentiels et de corriger le cap avant que Claude n’ait produit des centaines de lignes dans la mauvaise direction. Le pattern Plan → Execute → Verify structure chaque interaction. Demandez d’abord un plan, validez-le, puis lancez l’exécution. En pratique, cette approche réduit les itérations de correction de 60 % sur des tâches complexes.

La troisième règle est d’itérer par feedback plutôt que de réécrire vos prompts depuis zéro. Itérez par feedback au lieu de réécrire vos prompts depuis zéro. Quand Claude Code produit un résultat imparfait, la tentation est de repartir d’un prompt entièrement reformulé. C’est généralement une perte de temps. Un feedback ciblé « Le hook useAuth que tu viens de créer ne gère pas le cas de l’expiration du token, corrige ce point spécifiquement » est bien plus efficace qu’un nouveau prompt qui repart de zéro. Corrigez Claude dès que vous remarquez qu’il s’écarte de la bonne voie. Les meilleurs résultats proviennent de boucles de rétroaction serrées.

La quatrième règle concerne la précision des demandes de correction. Quand un bug persiste, ne dites pas simplement « ça ne marche pas ». Partagez les erreurs en copiant le texte d’erreur complet cela aide Claude à diagnostiquer. Soyez spécifique : corriger le bug quand je clique sur soumettre bat corriger le bug. Le texte d’erreur complet, le comportement observé et le comportement attendu constituent le trio d’informations qui permet à Claude de résoudre un bug précisément sans tâtonner ni générer des corrections approximatives.

La cinquième règle est de fournir des exemples de code existant pour guider le style de génération. Fournissez des exemples de code existant pour guider le style de génération. Pointer Claude vers un fichier de votre codebase qui représente le standard de qualité attendu « génère ce composant en suivant le même pattern que ProductCard.tsx » produit des résultats cohérents avec votre base de code existante, sans avoir à tout spécifier dans le prompt. C’est l’une des utilisations les plus puissantes et les moins exploitées de Claude Code.

Intégrer Git dans son workflow Claude Code

L’intégration de Git dans votre workflow Claude Code n’est pas simplement une bonne pratique de développement c’est votre filet de sécurité absolu. Sans elle, vous exposez votre base de code à des modifications non maîtrisées qui peuvent être difficiles à défaire et catastrophiques sur des branches sensibles. Avec elle, vous transformez Claude Code en partenaire de développement discipliné et traçable.

La première règle fondamentale est de toujours demander à Claude de créer une nouvelle branche avant chaque tâche. La pratique la plus importante pour la sécurité est d’utiliser un flux de travail Git discipliné. Demandez toujours à Claude de créer une nouvelle branche pour chaque tâche, ce qui isole son travail et vous offre un filet de sécurité pour facilement écarter les modifications si elles tournent mal. Ce réflexe simple une tâche, une branche vous garantit que le travail de Claude n’impacte jamais directement votre branche principale. Si le résultat ne vous convient pas, vous supprimez la branche et repartez d’une base propre sans aucune conséquence sur le reste du projet.

La deuxième règle concerne le contrôle absolu sur les commits. C’est l’une des règles comportementales les plus importantes à inscrire dans votre fichier CLAUDE.md. Ne jamais commiter automatiquement est une règle comportementale essentielle à définir dans votre CLAUDE.md. Claude Code peut générer des commits de façon autonome si vous ne lui imposez pas cette contrainte explicitement. Or, un commit automatique sur une branche partagée même avec un message bien rédigé peut introduire des modifications non relues dans votre historique Git. Vous restez le seul décisionnaire sur ce qui entre dans l’historique de votre projet.

Troisième bonne pratique : exploiter Claude Code pour automatiser les tâches mécaniques de Git sans renoncer au contrôle sur les décisions importantes. Laissez Claude gérer les parties mécaniques de Git créer des branches, faire des commits, rédiger les descriptions de PR pour que vous puissiez vous concentrer sur la revue des changements de code réels. La rédaction de messages de commit clairs, la création de descriptions de Pull Request détaillées, la gestion des branches de feature toutes ces tâches chronophages et à faible valeur ajoutée sont parfaitement déléguables à Claude Code. Ce qui ne l’est pas, c’est la décision finale de merger ou de valider les changements.

La quatrième dimension de l’intégration Git est l’utilisation de Claude Code pour les code reviews automatisées. Créez une commande partagée pour les code reviews en créant un fichier review.md dans le dossier .claude/commands/. Ce workflow vérifie la conformité aux conventions du projet, identifie les problèmes de performance, suggère des améliorations de lisibilité et vérifie la couverture de tests. Cette commande personnalisée, disponible via /project:review, transforme Claude Code en reviewer systématique qui applique les mêmes critères à chaque Pull Request sans fatigue, sans oubli et sans variabilité humaine. Pour les équipes, c’est un outil de standardisation de la qualité particulièrement précieux.

Cinquième levier à exploiter : la vérification systématique du build avant tout commit. Toujours lancer le build avant de dire que c’est fait est une règle comportementale essentielle. Sans cette vérification, Claude peut déclarer une tâche terminée alors que le code ne compile pas ou que les tests échouent. Inscrire cette règle dans votre CLAUDE.md garantit que Claude Code ne considère jamais une tâche comme terminée sans avoir vérifié que le projet compile correctement. Cette simple contrainte élimine une classe entière d’erreurs les modifications qui semblent correctes localement mais qui cassent le build avant qu’elles n’entrent dans votre historique Git.

Enfin, pensez à exploiter Claude Code pour la gestion des conflits de merge. Sur des projets où plusieurs développeurs travaillent simultanément, les conflits Git sont inévitables. Claude Code peut analyser les deux versions conflictuelles, comprendre l’intention de chaque modification et proposer une résolution cohérente avec l’architecture du projet une tâche qui peut prendre des dizaines de minutes manuellement et que Claude Code résout en quelques échanges ciblés.

Créer des commandes personnalisées et automatiser ses workflows

L’une des fonctionnalités les plus puissantes et les plus sous-exploitées de Claude Code est son système de commandes personnalisées. Là où la plupart des développeurs se contentent d’utiliser les commandes intégrées, les utilisateurs avancés construisent un arsenal de commandes sur mesure qui automatisent leurs workflows répétitifs et standardisent leurs pratiques d’équipe. C’est précisément ce levier qui explique les gains de productivité les plus spectaculaires observés en conditions réelles.

Le principe est simple mais puissant. Chaque fichier markdown placé dans le dossier .claude/commands/ devient une commande slash. Un fichier nommé review.md crée la commande /project:review. Les commandes committées dans le dossier projet sont partagées avec toute l’équipe. Les commandes placées dans ~/.claude/commands/ sont personnelles et disponibles dans tous vos projets. Cette distinction entre commandes projet et commandes personnelles est fondamentale elle vous permet de standardiser les pratiques collectives tout en conservant vos préférences individuelles dans tous vos environnements de développement.

La première commande personnalisée à créer pour tout projet sérieux est celle de code review automatisée. Créez une commande partagée pour les code reviews dans le dossier .claude/commands/. Un fichier review.md peut vérifier la conformité aux conventions du projet, identifier les problèmes de performance, suggérer des améliorations de lisibilité et vérifier la couverture de tests. En pratique, une équipe de 5 développeurs gagne environ 12 heures par semaine en standardisant ses interactions avec Claude Code. Ces douze heures hebdomadaires représentent plus de 600 heures annuelles un gain qui justifie largement l’investissement initial de configuration.

La deuxième famille de commandes essentielles concerne les workflows de génération de code récurrents. Chaque projet a ses patterns répétitifs créer un nouveau composant React avec ses tests et sa documentation, générer un endpoint API avec sa validation et son handler d’erreur, scaffolder une migration de base de données. Chacun de ces patterns peut être encapsulé dans une commande personnalisée qui garantit une cohérence absolue à chaque exécution. Les développeurs qui appliquent ces pratiques et documentent leurs workflows réutilisables dans des fichiers de mémoire persistante réduisent sensiblement le nombre d’itérations nécessaires pour obtenir un résultat satisfaisant.

Troisième usage avancé : le path scoping des commandes. Vous pouvez ajouter un bloc YAML frontmatter à un fichier de règle pour qu’il ne s’active que lorsque Claude travaille dans les répertoires correspondants. Un fichier de conventions API ne se chargera pas quand Claude édite un composant React. Le contexte reste léger et les règles restent pertinentes. Cette granularité contextuelle est particulièrement précieuse sur les monorepos ou les projets full-stack où les conventions front-end et back-end sont radicalement différentes. Vos commandes de génération de composants React ne polluent pas le contexte quand Claude travaille sur vos services Node.js et vice versa.

Quatrième dimension à exploiter : l’automatisation via le mode sans tête. Vous pouvez exécuter Claude en mode sans tête avec le drapeau -p, ce qui vous permet de lancer une invite à partir d’un script. C’est parfait pour des tâches comme trier automatiquement les nouveaux problèmes GitHub ou générer du code modèle. Vous pouvez également configurer des hooks des commandes shell qui s’exécutent automatiquement avant ou après que Claude fasse quelque chose comme modifier un fichier. Cela vous permet de déclencher un linter ou un vérificateur de type sans y penser. Eesel AI Cette intégration dans le pipeline CI/CD transforme Claude Code d’un assistant interactif en composant d’automatisation — capable d’agir sur des événements déclencheurs sans intervention humaine.

Cinquième levier : la documentation et le partage des workflows qui fonctionnent. Capitalisez sur vos apprentissages en documentant les workflows qui fonctionnent. Les équipes qui documentent cinq workflows personnalisés ou plus réduisent notablement leur temps d’onboarding de nouveaux développeurs. Chaque commande personnalisée bien documentée est un investissement dans la montée en compétences collective un nouveau développeur qui rejoint l’équipe hérite immédiatement de l’ensemble des bonnes pratiques encodées dans ces commandes, sans avoir à les découvrir par tâtonnement.

Choisir le bon modèle selon la complexité de la tâche

L’une des décisions les plus structurantes pour optimiser votre utilisation de Claude Code en termes de coût, de performance et de vitesse est le choix du modèle utilisé pour chaque type de tâche. Claude Code vous donne accès à plusieurs modèles aux capacités et aux tarifications différentes, et savoir lequel mobiliser selon le contexte est une compétence qui distingue les utilisateurs avancés des utilisateurs occasionnels.

La règle de base est claire et repose sur une logique simple de proportionnalité entre la complexité de la tâche et la puissance du modèle mobilisé. Utilisez Sonnet 4.6 pour environ 80 % de votre travail : écrire des fonctions, corriger des bugs, ajouter des fonctionnalités, écrire des tests, expliquer du code. Il est rapide, économique et plus que compétent. Passez à Opus 4.6 pour les 20 % les plus difficiles : refactorisations à grande échelle sur de nombreux fichiers, décisions architecturales complexes, ou quand vous avez besoin de la fenêtre de contexte de 1M tokens pour analyser une grande base de code. Cette répartition 80/20 est un guide pratique qui vous permet de maîtriser vos coûts d’utilisation tout en réservant la puissance maximale aux situations qui la justifient réellement.

La première catégorie de tâches qui relèvent naturellement de Sonnet 4.6 est celle des opérations unitaires bien délimitées. Écrire une fonction utilitaire, corriger un bug identifié, ajouter un champ à un formulaire, rédiger des tests unitaires pour un composant existant, documenter une API ou expliquer un morceau de code inconnu sont des tâches pour lesquelles Sonnet offre des performances excellentes à une fraction du coût d’Opus. Sa rapidité d’exécution est également un atout majeur pour les workflows itératifs où vous échangez fréquemment des messages courts avec Claude Code.

La deuxième catégorie de tâches qui justifient le recours à Opus 4.6 est celle des décisions architecturales et des refactorisations à grande échelle. Quand vous devez restructurer un module entier, migrer une codebase vers un nouveau framework, analyser l’ensemble des dépendances d’un projet pour identifier des problèmes de performance ou concevoir l’architecture d’une nouvelle fonctionnalité critique, la capacité de raisonnement supérieure d’Opus fait une différence mesurable sur la qualité du résultat. Claude Code excelle sur les tâches d’architecture, de refactoring et d’automatisation CI/CD grâce à sa compréhension contextuelle du codebase entier.

Un troisième critère de choix souvent négligé est celui de la taille de la fenêtre de contexte nécessaire. Si votre tâche implique l’analyse simultanée d’un grand nombre de fichiers ou d’une base de code volumineuse, Opus avec sa fenêtre de contexte étendue de 1M tokens devient incontournable. Sonnet, avec une fenêtre de contexte plus limitée, peut perdre des informations importantes sur des tâches nécessitant de maintenir simultanément beaucoup de contexte en mémoire. Évaluez donc non seulement la complexité de la tâche mais aussi le volume d’information que Claude devra maintenir en contexte pour la réaliser correctement.

La quatrième dimension à considérer est celle du rapport qualité/coût/vitesse selon votre situation. En 2026, les outils de coding agentique comme Claude Code évoluent rapidement. Restez à jour en vérifiant régulièrement les release notes et en adaptant vos pratiques. Node.js 22 LTS et Python 3.12 restent les environnements recommandés pour une compatibilité optimale. Les tarifications et les capacités relatives des modèles évoluent régulièrement. Une bonne pratique consiste à réévaluer périodiquement votre stratégie de sélection de modèle à mesure que les nouvelles versions sont publiées par Anthropic.

Enfin, une règle pratique pour les équipes : documentez votre stratégie de choix de modèle dans votre CLAUDE.md. Précisez explicitement quel modèle utiliser pour quels types de tâches au sein de votre projet. Cette documentation évite les dépenses superflues liées à l’utilisation d’Opus pour des tâches simples que Sonnet gère parfaitement, et garantit que les tâches critiques bénéficient toujours de la puissance de modèle qu’elles méritent.