Comment les équipes d’Anthropic utilisent Claude Code

 (anthropic.com)
37 points par GN⁺ 2025-07-27 | 1 commentaires | Partager sur WhatsApp
  • Les différents départements d’Anthropic (infrastructure de données, développement produit, sécurité, inférence, data science, marketing, design, ingénierie RL, juridique, etc.) ont adopté Claude Code et constatent des transformations majeures en matière d’automatisation de projets complexes, d’efficacité opérationnelle et d’extension des capacités des non-développeurs
  • Reprise après incident Kubernetes, onboarding des nouvelles recrues, supervision de données à grande échelle, automatisation de workflows non techniques pour l’équipe finance : Claude Code apporte des solutions concrètes et améliore réellement la productivité
  • Grâce au prototypage rapide, à l’exploration de codebase, à la génération automatique de tests et à l’automatisation des tâches répétitives, les équipes obtiennent des gains de temps de 2 à 4 fois, ainsi qu’une amélioration de la vitesse et de la qualité de développement
  • Même les équipes non techniques comme le design, le marketing ou le juridique peuvent désormais, via des agents sur mesure et des intégrations avec Figma/Google Ads/Meta Ads, créer des automatisations et des outils complexes sans mobiliser de ressources d’ingénierie
  • Chaque équipe partage aussi ses principaux conseils d’usage : documentation dans Claude.md, checkpoints réguliers, prompts précis, feedback visuel, partage des workflows au sein de l’équipe, etc.

Vue d’ensemble

Anthropic applique Claude Code dans plusieurs équipes internes, permettant aussi bien aux développeurs qu’aux non-développeurs de traiter des projets complexes, d’automatiser les tâches répétitives et de réduire la courbe d’apprentissage, avec à la clé une véritable transformation de la productivité. L’article explique en détail comment 10 départements utilisent concrètement Claude Code, ainsi que les méthodes efficaces, les points d’attention lors de l’adoption et les bonnes pratiques associées.

Équipe Data Infrastructure : utiliser Claude Code pour l’infrastructure de données

Principaux cas d’usage

  • Débogage Kubernetes
    • En cas d’incident sur un cluster Kubernetes, l’équipe fournit à Claude Code une capture d’écran du dashboard ; celui-ci indique le chemin à suivre dans l’interface Google Cloud et suggère les commandes nécessaires à la résolution
  • Workflows en langage naturel pour les non-développeurs
    • Des équipes comme la finance peuvent décrire un flux de données en texte courant ; Claude Code exécute alors automatiquement le workflow, pose des questions sur les entrées nécessaires et produit par exemple un résultat dans Excel
  • Exploration de la codebase pour les nouveaux arrivants
    • Un data scientist récemment recruté peut utiliser Claude Code pour comprendre la documentation Claude.md et la structure de la codebase, obtenir des explications sur les dépendances des pipelines de données et identifier la source des dashboards
  • Résumé automatique de la documentation en fin de session
    • À la fin de chaque tâche, Claude peut résumer automatiquement le travail effectué et proposer des améliorations pour la documentation Claude.md
  • Travail parallèle sur plusieurs instances
    • Plusieurs instances de Claude Code peuvent être utilisées en parallèle sur différents dépôts, ce qui permet de passer d’un projet à l’autre sans perdre l’état du workflow ni le contexte

Impact sur l’équipe

  • Résolution de problèmes d’infrastructure sans aide d’experts
  • Accélération majeure de l’onboarding des nouveaux arrivants
  • Renforcement des workflows de support, notamment pour l’automatisation de la détection d’anomalies de données
  • Mise en place du self-service pour les équipes non techniques

Conseils clés

  • Documenter en détail dans le fichier Claude.md
  • Pour les données sensibles, privilégier un serveur MCP plutôt que la CLI BigQuery
  • Partager les sessions d’usage au sein de l’équipe pour diffuser les bonnes pratiques

Équipe Product Development : utiliser Claude Code pour le développement produit

Principaux cas d’usage

  • Prototypage rapide via des boucles d’automatisation
    • Après avoir activé le mode auto-accept, l’équipe confie à Claude un problème abstrait, récupère un résultat abouti à 80 %, puis effectue les ajustements finaux
  • Codage synchrone (collaboration en temps réel)
    • Lors du développement de fonctionnalités clés, l’équipe fournit en temps réel des prompts et des guidelines de code, tandis que Claude prend en charge l’implémentation répétitive
  • Implémentation de fonctionnalités autonomes comme le mode Vim
    • Plus de 70 % de la fonctionnalité est implémentée automatiquement, puis finalisée par itérations successives
  • Automatisation des tests et de la correction de bugs
    • Au stade de la revue de PR, Claude applique automatiquement des corrections de format, des renommages de fonctions, etc.
  • Exploration rapide de la codebase
    • Même dans une monorepo complexe ou dans le code côté API, l’équipe peut interroger Claude sur la structure et les dépendances

Impact sur l’équipe

  • Implémentation rapide de fonctionnalités complexes grâce à l’automatisation
  • Réduction du temps nécessaire pour itérer et étendre des prototypes
  • Amélioration de la couverture de tests automatisés et de la qualité du code
  • Exploration plus efficace de codebases inconnues

Conseils clés

  • Mettre en place sa propre boucle de validation (build, tests, lint automatisés)
  • Distinguer les tâches synchrones et asynchrones
  • Rédiger des prompts clairs et précis

Équipe Security Engineering : appliquer Claude Code à l’ingénierie sécurité

Principaux cas d’usage

  • Débogage d’infrastructures complexes
    • En lui fournissant une stack trace et de la documentation, Claude suit le control flow
  • Revue et analyse de code Terraform
    • L’équipe soumet un plan à Claude pour examiner rapidement l’impact sécurité et accélérer la validation
  • Consolidation documentaire et création de runbooks
    • Après agrégation de plusieurs documents, Claude génère des guides de troubleshooting et des résumés de runbooks
  • Mise en œuvre du développement piloté par les tests (TDD)
    • L’équipe collabore avec Claude sur un cycle pseudocode → TDD → vérifications régulières
  • Réduction du coût des changements de contexte et onboarding
    • En fournissant une spécification Markdown à Claude, de nouveaux membres peuvent contribuer rapidement à l’équipe

Impact sur l’équipe

  • Temps de réponse aux incidents d’infrastructure réduit à moins de 5 minutes
  • Suppression du temps d’attente pour les validations sécurité
  • Contribution possible à d’autres projets en peu de temps
  • Efficacité maximale des workflows documentaires

Conseils clés

  • Exploiter activement les slash commands personnalisées
  • Donner à Claude davantage d’autonomie pour coder
  • Préciser clairement la documentation attendue et le format de sortie

Équipe Inference : utilisation pour la gestion des systèmes d’inférence

Principaux cas d’usage

  • Compréhension rapide de la codebase et onboarding
    • Il est possible de demander immédiatement à Claude quels fichiers appellent telle fonctionnalité ou quelles sont les dépendances
  • Génération automatique de tests, y compris pour les edge cases
    • Après l’implémentation d’une fonctionnalité, Claude génère les tests et l’équipe se concentre sur la vérification
  • Explication de concepts de machine learning
    • Claude peut expliquer les fonctions et réglages propres à chaque modèle, avec un gain de temps de 80 % par rapport à une recherche Google
  • Conversion de code entre plusieurs langages
    • La logique souhaitée peut être convertie dans un langage peu familier comme Rust
  • Assistance continue sur les commandes Kubernetes

Impact sur l’équipe

  • Réduction de 80 % du temps consacré à la recherche et à l’apprentissage en machine learning
  • Exploration immédiate de la codebase
  • Maintien de la qualité grâce aux tests automatisés
  • Réduction de la barrière liée aux langages

Conseils clés

  • Commencer par interroger la base de connaissances
  • Faire valider les résultats après génération de code
  • Demander explicitement la rédaction des tests pour réduire la charge

Équipes Data Science et ML Engineering : data science et ingénierie machine learning

Principaux cas d’usage

  • Création d’applications dashboard en JavaScript/TypeScript
    • Même avec très peu d’expérience en JS/TS, il devient possible de créer un dashboard React complet, utile par exemple pour analyser les performances de modèles RL
  • Automatisation du refactoring répétitif
    • Les tâches répétitives comme les conflits de fusion ou les changements de structure de fichiers peuvent être entièrement automatisées pendant 30 minutes, puis adoptées telles quelles si le résultat est concluant
  • Développement d’outils d’analyse pérennes
    • Au lieu de notebooks à usage unique, l’équipe construit des dashboards React réutilisables pour l’analyse des performances des modèles
  • Délégation de tâches sans dépendance à une expertise préalable
    • Même un travail dans un langage ou une codebase totalement inconnus peut être confié à Claude de bout en bout

Impact sur l’équipe

  • Refactoring quotidien au moins 2 à 4 fois plus rapide
  • Création d’applications complexes même dans des langages peu maîtrisés
  • Passage d’outils d’analyse ponctuels à des outils durables
  • Amélioration du niveau de décision grâce à la visualisation des performances des modèles

Conseils clés

  • L’utiliser comme une machine à sous : accepter ou relancer selon le résultat
  • Plus le problème est complexe, plus il faut intervenir directement et pousser à la simplification

Équipe Product Engineering : usages terrain en ingénierie produit

Principaux cas d’usage

  • Commencer par demander à Claude la liste des fichiers et des chemins pour concevoir rapidement le workflow
  • Déboguer des bugs et développer des fonctionnalités de manière autonome dans des codebases peu familières
  • Dogfooding grâce à l’expérimentation des modèles de recherche les plus récents
  • Amélioration de la concentration grâce à la réduction du coût des changements de contexte

Impact sur l’équipe

  • Capacité à travailler de façon autonome jusque dans des zones inconnues du code
  • Réduction de la charge liée aux changements de contexte et à l’attente de réponses
  • Onboarding accéléré des ingénieurs en rotation
  • Hausse de la satisfaction et de la productivité des développeurs

Conseils clés

  • Le considérer comme un partenaire de collaboration et travailler par itérations
  • Oser se lancer sur des tâches inconnues
  • Démarrer avec un minimum d’informations puis avancer en suivant les indications de Claude

Équipe Growth Marketing : automatisation du marketing de croissance

Principaux cas d’usage

  • Génération automatique de textes Google Ads
    • Création de titres et descriptions publicitaires adaptés aux limites de caractères de chaque emplacement, pour automatiser la production d’annonces à grande échelle
  • Production massive de créations via un plugin Figma
    • Génération programmatique de plusieurs images et textes publicitaires, jusqu’à 100 variantes
  • Analyse en temps réel des données Meta Ads via un serveur MCP
    • Automatisation de l’analyse des performances de campagne, des dépenses médias, etc.
  • Journalisation des expérimentations répétées via un système de mémoire
    • Les résultats des tests créatifs sont enregistrés puis réutilisés pour les générations suivantes

Impact sur l’équipe

  • Temps de création de textes publicitaires réduit de 2 heures à 15 minutes
  • Production créative multipliée par plus de 10
  • Une équipe marketing d’une seule personne peut prendre en charge directement des tâches de développement et d’analyse à grande échelle
  • Déplacement du focus vers la stratégie globale et l’automatisation

Conseils clés

  • Commencer par examiner les tâches répétitives pouvant être automatisées via des intégrations API
  • Découper les grands workflows en sous-agents par rôle
  • Concevoir et structurer soigneusement les prompts dans Claude.ai avant l’implémentation dans Claude Code

Équipe Product Design : transformation du travail de design produit

Principaux cas d’usage

  • Amélioration visuelle du frontend et ajustement direct de la gestion d’état
    • Les designers peuvent améliorer immédiatement l’UI et implémenter des changements d’état avec Claude Code
  • Ticketing basé sur GitHub Actions et suggestions automatiques de code
    • Pour les demandes frontend ou les corrections de bugs, Claude propose automatiquement du code
  • Création rapide de prototypes interactifs
    • Coller une image de maquette permet de générer immédiatement du code fonctionnel
  • Identification des edge cases et compréhension de l’architecture
    • Les designers explorent directement les états système et les flux d’erreur dès la phase de conception
  • Modifications complexes de copy et gestion de conformité en temps réel
    • Un libellé précis peut être modifié en masse dans toute la codebase, en collaboration directe avec le juridique

Impact sur l’équipe

  • Bascule vers un travail centré sur Figma et Claude Code
  • Améliorations visuelles et de gestion d’état 2 à 3 fois plus rapides
  • Des projets collaboratifs complexes ramenés d’une semaine à une heure
  • Expériences différenciées pour développeurs et designers
  • Nette amélioration de la communication et du niveau de conception

Conseils clés

  • Une aide d’ingénieurs est nécessaire pour la configuration initiale
  • Définir à l’avance le rôle et le mode d’explication via des fichiers de mémoire personnalisés
  • Créer des prototypes en collant des images

Équipe RL Engineering : échantillonnage RL et gestion des poids

Principaux cas d’usage

  • Adopter un mode autonome + supervisé pour le développement de petites et moyennes fonctionnalités
  • Automatiser la génération de tests et la revue de code
  • Utiliser Claude pour le débogage et l’analyse d’erreurs
  • Automatiser les résumés de codebase et l’analyse de call stacks
  • Appui opérationnel via des questions liées à Kubernetes

Évolution des méthodes de travail

  • Généralisation d’une approche par checkpoints expérimentaux et rollback
  • Gain de temps grâce à la génération automatique de documentation
  • Pour les PR de petite à moyenne taille, environ un tiers aboutissent du premier coup

Conseils clés

  • Indiquer dans Claude.md les erreurs récurrentes à éviter
  • Prendre l’habitude de commit fréquemment et de faire des rollbacks
  • Appliquer un schéma one-shot puis collaboratif

Équipe Legal : usages de l’IA par l’équipe juridique

Principaux cas d’usage

  • Personnalisation rapide de solutions d’accessibilité personnelles
    • Création directe d’outils comme une application de texte prédictif pour un usage familial
  • Prototypes d’automatisation de workflows au sein du département
    • Automatisation de tâches comme des arbres de routage téléphonique ou des workflows connectés à G Suite
  • Innovation centrée sur le prototype
    • Création rapide de prototypes, collecte de retours d’experts puis validation en usage réel
  • Développement et feedback centrés sur le visuel
    • Communication avec Claude à partir de captures d’écran d’interface

Perception de la sécurité et de la conformité

  • Les enjeux de sécurité deviennent immédiatement visibles via l’intégration MCP
  • Avec l’extension des systèmes d’IA, la création d’outils de conformité devient prioritaire

Conseils clés

  • Bien concevoir et structurer les idées dans Claude.ai avant de se lancer
  • Réduire la charge en formulant les demandes étape par étape et à partir de captures d’écran
  • Partager activement même des prototypes encore imparfaits

À lire aussi

1 commentaires

 
GN⁺ 2025-07-27
Commentaire Hacker News
  • Claude Code a tendance à ne faire que 70 à 80 % du travail, et j’aimerais que ce point soit davantage mis en avant. Par exemple, des conseils du genre « utilise-le comme une machine à sous », « sauvegarde l’état avant de lancer une session de 30 minutes, puis accepte le résultat ou repars de zéro, c’est mieux que d’essayer de corriger en cours de route » sont amusants. Mais c’est facile à dire quand ce n’est pas toi qui paies directement le coût du compute
    • Du point de vue d’un employé, le conseil « même si le résultat est bon, fais générer et modifier le code des centaines de fois » est assez drôle. À ce rythme, l’entreprise va surtout recevoir une facture énorme pour très peu de commits réels. Au point qu’on en arrive à plaisanter en disant : « On pensait que l’IA allait tout régler, mais il va falloir embaucher encore plus de développeurs »
    • De mon côté, j’utilise assez bien les LLM pour générer du code. Ma règle, c’est que ça n’en vaut la peine que si plus de 90 % de la tâche entière peut être fait par l’IA, hors autocomplétion simple ou petites retouches de texte. Pour les problèmes présents dans les données d’entraînement, par exemple configurer un petit serveur web en golang, on est presque à 100 % de précision. Ce genre de choses se règle en quelques minutes, et ça permet de poser rapidement le code « plat » de l’architecture. En pratique, ma productivité augmente vraiment de 30 à 50 %
    • Ce que j’ai réalisé récemment, c’est que ce comportement « 70-80 % terminé » de Claude peut s’appliquer non seulement au début d’un projet, mais aussi à la toute fin. J’étais en train de faire moi-même un gros refactoring depuis zéro, puis une fois l’idée esquissée, je l’ai passé à Claude, qui a terminé le reste parfaitement, jusqu’au CHANGELOG. J’y vois un bon exemple de prompt centré sur l’exemple ou de garde-fous très forts
    • Si je devais ajouter quelque chose à la métaphore de la machine à sous, ce serait qu’il vaut mieux augmenter au maximum la rigueur formelle du système quand c’est possible. Si tu codes à la légère en Python pour t’amuser, tu finiras avec un mauvais résultat. En Haskell, si tu renforces les vérifications formelles avec les options GHC ou les property tests, Claude se fait rattraper quand il essaie de tricher. En TypeScript aussi, forcer une structure plus stricte via le système de types est efficace. Comme Claude semble obsédé par les cases TODO, ça finit par le pousser à faire exactement ce qu’on lui demande
    • Si un employé écrivait habituellement du code correct mais avait 30 % de chances de soumettre un code complètement aberrant, inutilisable au point de devoir tout refaire, il serait probablement licencié
  • J’ai déjà utilisé CC pour implémenter une application web entière. J’ai aussi testé divers outils de coding IA et donné des cours et ateliers sur le sujet. Le workflow le plus efficace avec CC, c’est de rédiger une spécification claire et concise dans un fichier md. Ensuite, je la référence explicitement dans chaque prompt. Je commence par les user stories, je fais rédiger à CC un premier plan étape par étape, puis j’itère entre corrections et validation. Après ça, je lui fais exécuter les tâches de manière compartimentée selon les consignes d’implémentation. Sans oublier les tests automatisés, les tests fonctionnels, puis le merge à la fin
    • Bon conseil, c’est proche de mon expérience. Au début, j’ai plutôt tendance à lancer un prompt approximatif puis à itérer. J’ai aussi documenté mon propre workflow ici
    • Je me demande si cette manière de travailler est réellement plus rapide ou plus efficace que d’écrire directement le code soi-même
    • S’il y a un exemple concret réalisé de cette façon, je serais curieux qu’on le partage
    • J’ai eu une expérience proche de ce workflow, mais je déteste tellement travailler comme ça que je préfère presque toujours coder moi-même. Rédiger des specs ou des user stories est vraiment ce que j’aime le moins
  • Claude Code convient bien à des tâches variées. Hier, j’ai changé l’API backend d’un site météo, et même si les deux API étaient assez différentes, il a quasiment tout fait d’un coup. Chez moi, j’utilise l’abonnement à 20 $/mois, et au travail on fait un pilote via AWS Bedrock. Quand on l’utilise via l’API Bedrock, le coût s’affiche immédiatement à la fin de chaque session, et c’est un peu déstabilisant. Je crains qu’à long terme, si cette facturation détaillée à l’usage devient la norme, les développeurs hésitent davantage à essayer des choses, à expérimenter ou à refactorer, et que la qualité globale des logiciels en pâtisse. En interne chez Anthropic, ils ont sans doute la chance d’éviter ce problème puisqu’ils l’utilisent probablement sans se soucier des coûts
    • Il y a quelques semaines, je lui ai donné l’API MLB et demandé de me créer un widget MacOS ; en moins d’une heure il m’a sorti un widget qui affichait les classements de ligue, division et wild card. Pour un projet quick-and-dirty qu’on peut vérifier en dix minutes, c’est franchement utile. J’ai d’autres exemples similaires de ce type
    • Par le passé, les ingénieurs devaient déjà faire attention aux coûts des datacenters, du cloud, du SaaS, etc. Pendant les 5 à 10 prochaines années, j’ai l’impression qu’ils devront aussi surveiller les frais d’usage de l’IA. Au bout du compte, on arrivera à une période où le coût de l’IA deviendra négligeable par rapport au coût du temps humain

    • Il était dit que « voir directement le coût est désagréable », mais franchement, même si ma session monstre sur Claude coûte 10 $ à l’entreprise, ça m’est égal. D’ailleurs, au boulot on m’a dit : « ne te préoccupe pas du coût, commence déjà par expérimenter »

    • De mon côté, même sur une fonction triviale, si je demande à Claude de l’écrire, il l’implémente souvent de travers de façon subtile, mais les tests le révèlent immédiatement ; je me dis donc qu’il vaudrait mieux être plus prudent
    • Je trouve curieux d’être surpris par le fait de voir directement le coût d’usage. Bien sûr, je n’aimerais pas qu’on me l’affiche de manière excessive, mais quand on expérimente des prompts pour agent, c’est utile de pouvoir voir le coût par requête. Il arrive qu’une seule phrase dans le prompt change le coût, donc cette information peut justement orienter l’innovation, non ? Pourquoi y voir un effet dissuasif ? J’ai l’impression que beaucoup d’ingénieurs vont au contraire se concentrer sérieusement sur l’innovation pour réduire les coûts
  • Depuis quelques jours, je suis passé de Gemini Cli à Claude Code. Je reconnais que la boucle d’utilisation des outils est meilleure. En revanche, Claude est un peu plus « bête » et essaie d’achever la tâche de force. Il ignore le bon sens ou même des instructions explicites. Par exemple, si on lui dit de faire passer les tests, il peut aller jusqu’à modifier la structure de la base de données au lieu de déboguer. Deux fois, il m’a même supprimé tous les protobufs pour les remplacer par du JSON. J’ai l’impression que comme les proto ne se déboguaient pas facilement, il a choisi cette « solution » par défaut
    • J’ai vécu quelque chose de similaire. En plein petit refactoring, après avoir correctement avancé sur la moitié du travail, dès que ça commence à coincer, il annule tous les changements précédents et se lance précipitamment dans une automatisation complète via un script bash. Quand on lui fait remarquer : « tu avais presque fini, qu’est-ce que tu fabriques ? », il le reconnaît tout de suite. C’est typique de son côté très affirmé mais qui change d’avis immédiatement
    • Le fait que Claude essaie de « faire semblant » de réussir les tests en trichant correspond exactement à mon expérience. Il supprime parfois les tests eux-mêmes ou les saute, puis annonce « tout est résolu ! ». Curieusement, je n’ai jamais vu ça avec d’autres LLM ; d’ordinaire, ils admettent l’échec et, avec un peu plus d’indications, finissent par résoudre le problème proprement. Claude, lui, semble partir du principe que je vais me faire avoir. Je m’inquiète de ce que ça donnerait sur des défauts plus critiques
    • J’ai eu un cas très similaire. Quand une suite de tests globale et complexe échoue, au lieu de chercher la cause, il remplace ça par des tests fragmentaires plus faciles à faire passer. Je me demande si l’équipe Claude ne pousse pas surtout à aller vite pour économiser du compute. Il y a aussi souvent des timeouts API ou des erreurs
    • Ce qui est amusant, c’est que dès qu’un problème survient à n’importe quelle étape, Claude a tendance à le balayer avec une formule du genre « tâche reportée (Deferred) » accompagnée d’un prétexte plus ou moins crédible. Un humain peut décider de reporter un travail grâce à son jugement ; une machine n’a pas ce jugement, donc à mon avis il ne faut pas accepter cette attitude
    • J’ai même entendu dire que quelqu’un avait vu Claude supprimer en masse des morceaux du codebase, puis nier l’avoir fait
  • J’utilise bien Claude, mais le billet de blog que j’ai lu aujourd’hui m’a paru un peu maladroit et grossier. J’ai même eu l’impression que l’équipe blog l’avait écrit avec Claude
    • Le site de documentation MCP a le même problème. On dirait juste une succession peu accueillante de puces
    • J’ai une impression similaire, mais je trouve que le vrai problème est davantage le contenu lui-même. Par exemple, la phrase « au lieu d’écrire des commandes Kubernetes complexes, demandez simplement à Claude et il vous donnera la bonne commande » me semble inutile dans un blog technique sur l’IA. Ce n’est qu’un conseil très basique
    • Le problème n’est pas de savoir si Claude a été utilisé ou non, mais que l’ensemble ressemble à une simple liste de réponses à un sondage, sans liaison, désordonnée, répétitive et sans aucun vrai travail d’édition. On ne sent aucune curation assumée par quelqu’un
    • Il y a beaucoup d’informations, mais au final ça donne juste l’impression d’une liste de puces raffinées, rien de plus
  • Le premier cas cité parlait d’un débogage k8s où Claude avait diagnostiqué un épuisement du pool d’IP et résolu le problème sans expert réseau. Mais je me suis demandé si, à l’origine, un expert réseau n’aurait pas conçu les choses de façon à éviter totalement ce problème
    • Les experts se trompent aussi. En réalité, tous les humains se trompent
  • Mon astuce d’optimisation du moment, c’est d’utiliser la saisie vocale avec Claude Code. Il suffit d’expliquer le contexte et l’historique comme si on parlait à une personne. C’est bien plus rapide que de tout taper
    • Si vous êtes sur Mac, l’application SuperWhisper est plutôt bonne
    • De mon côté, je suis satisfait du package Python hns. En terminal, je le lance avec <i>uvx hns</i> ; j’enregistre, puis j’appuie sur Entrée et le texte est automatiquement copié dans le presse-papiers. C’est simple, mais ça s’intègre naturellement à un workflow CLI. Lien
    • Parler à voix haute à une IA dans sa chambre ? Ce n’est pas un peu gênant ? Moi, au contraire, je tape plus vite
    • Je serais curieux de connaître une bonne option utilisable aussi sur Ubuntu
  • Il était question d’une panne de cluster Kubernetes où, avec Claude Code, on avait fourni des captures d’écran du dashboard, puis analysé pas à pas l’interface Google Cloud pour repérer une alerte d’épuisement des IP de pod et obtenir la marche à suivre pour ajouter un nouveau pool d’IP. Mais je trouve cette méthode inefficace et je doute qu’on ait vraiment eu besoin d’IA pour ça
    • À force de faire comme ça, on risque de figer une manière de résoudre les problèmes qui dépend de l’IA même pour des soucis simples. Au final, on peut en venir à perdre la compréhension du contexte, ou même le réseau de personnes expertes à qui demander de l’aide, et se retrouver dans un monde d’« esclaves de l’IA »
    • C’est le genre d’approche qu’on attendrait plutôt d’un stagiaire ou d’un ingénieur junior pour résoudre ce problème-là, ou alors c’était peut-être effectivement le cas
  • Cas intéressant : notre équipe voulait essayer Claude Code, mais il n’est pas inclus dans l’offre équipe, alors qu’il l’est dans l’offre Pro au même niveau de prix. On l’a découvert après l’achat, ce qui est assez décevant. On n’a pas l’intention d’imposer un paiement individuel à chaque développeur. Avant de vanter les usages internes de l’équipe, j’aimerais qu’ils améliorent d’abord la structure de paiement et d’abonnement pour que d’autres entreprises puissent aussi s’en servir. Ils construisent des modèles d’IA parmi les meilleurs du secteur, mais n’ont toujours pas réglé des problèmes de base comme la gestion des abonnements
    • Pourquoi penses-tu qu’il ne faut pas faire payer chacun individuellement ?
  • J’utilise surtout Claude Code comme un canard en plastique intelligent, pour discuter d’idées ou obtenir du feedback. La majorité du vrai code, je l’écris moi-même. Je commence par le pousser à bien expliquer ses avis et ses intentions dans le chat, puis je pose comme règle qu’il ne modifie le code que quand je le lui demande. J’importe ensuite le code dans l’IDE par simple copier-coller, et à mesure que j’apporte mes propres modifications, je lui explique aussi les changements. Au début, ça semble plus lent, mais au final je repère mieux les problèmes et j’affine plus vite dans la direction voulue. Claude ressemble à un développeur junior (trop) sûr de lui. Il faut bien le superviser, et si je suis plus rapide, autant faire les choses moi-même. (Ce serait sans doute une mauvaise méthode avec un junior, mais avec Claude ça marche bien.) Cela dit, il faut aussi garder à l’esprit que ce billet de blog a été écrit par une entreprise qui vend l’outil. À mon avis, il faut filtrer 90 % du marketing des boîtes d’IA. Au fond, on dirait qu’elles écrivent comme ça pour attirer de l’argent ou se faire racheter
    • En le laissant uniquement en mode plan, il ne modifie rien automatiquement, non ? Gemini CLI, lui, n’hésite pas à se lancer directement dans l’implémentation :D