Claude Code pour non-ingénieurs : workflows sûrs, prompts, permissions et usages métier

Claude Code n’est pas réservé aux développeurs. Les équipes marketing, opérations, support, RH, produit ou les fondateurs peuvent l’utiliser pour améliorer une page web, ranger une documentation, préparer un rapport CSV, créer une procédure interne ou transformer une demande floue en plan de travail vérifiable.

Mais il faut l’utiliser avec prudence. Claude Code peut lire des fichiers, les modifier et lancer des commandes. C’est puissant, donc une demande comme « corrige tout et publie » est trop risquée. Pour une personne non technique, la bonne pratique est simple : demander une petite tâche, lire le résumé du diff, puis arrêter dès que la tâche touche aux secrets, aux données clients, à la production, aux paiements ou à la sécurité.

Pour l’installation, consultez le guide de démarrage Claude Code. Pour les garde-fous, lisez aussi approval et sandbox ainsi que le guide des permissions Claude Code.

Les mots à comprendre

Le terminal est une fenêtre texte pour donner des instructions à l’ordinateur. Un diff montre ce qui a changé entre l’avant et l’après. Les permissions définissent ce que Claude Code peut faire sans demander, ce qui demande validation, et ce qui est interdit.

Terme	Sens simple	À vérifier
Terminal	Panneau de commande en texte	Êtes-vous dans le bon dossier ?
Diff	Liste des changements	Les bons fichiers ont-ils changé ?
Approval	Pause avant action	Comprenez-vous l’action ?
Sandbox	Zone de travail limitée	La commande reste-t-elle dans le périmètre ?
Secret	Token, clé API, mot de passe	Ne pas lire sans raison claire

Workflow sûr

flowchart LR
  A["Définir l'objectif"] --> B["Demander inspection seulement"]
  B --> C["Lire questions et risques"]
  C --> D["Approuver une petite édition"]
  D --> E["Lire le résumé du diff"]
  E --> F{"Production ou secrets ?"}
  F -->|Oui| G["Arrêter et demander à un ingénieur"]
  F -->|Non| H["Lancer les checks et décider"]

La phrase de départ la plus utile est : « Ne modifie pas encore les fichiers ». Elle force Claude Code à observer, poser des questions et proposer un plan.

Exemple de permissions

Documentation officielle à garder sous la main :

• Claude Code overview
• Configure permissions
• Claude Code settings
• Security

Pour commencer, autorisez la lecture et les vérifications, demandez validation pour les écritures, et bloquez les secrets ou commandes irréversibles.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Read",
      "Grep",
      "Glob",
      "Bash(npm run build)",
      "Bash(npm run test)"
    ],
    "ask": [
      "Edit",
      "Write",
      "Bash(git diff)",
      "Bash(git status)"
    ],
    "deny": [
      "Read(.env*)",
      "Read(**/secrets/**)",
      "Bash(rm -rf *)",
      "Bash(git reset --hard)",
      "Bash(git push *)",
      "Bash(npm publish *)"
    ]
  }
}

allow autorise, ask demande confirmation, deny bloque. Un fichier .env contient souvent des clés privées ou des tokens ; il ne doit pas être lu pour une simple tâche de contenu.

Transformer une demande floue en checklist

Agis comme un assistant de travail prudent. Ne modifie pas encore les fichiers.

Objectif :
Rendre la page de contact plus claire pour un nouveau client.

Merci de :
1. Trouver les fichiers probablement concernés.
2. Lister cinq questions à résoudre avant modification.
3. Découper le travail en petites tâches.
4. Marquer les tâches risquées qui nécessitent un ingénieur.
5. Recommander la plus petite tâche sûre à faire aujourd'hui.

Ce prompt fonctionne pour une page web, une FAQ, un document interne ou un modèle d’e-mail.

Cas 1 : texte d’un site web

Ne publie rien et ne déploie rien.

Relis seulement le texte de la page tarifs.
Fichiers :
- site/src/content/pricing.mdx
- site/src/pages/pricing.astro

Tâches :
1. Repérer les formulations peu claires pour un nouveau client.
2. Proposer des remplacements dans un tableau.
3. Attendre mon accord.
4. Appliquer uniquement les textes approuvés.
5. M'expliquer le git diff en français simple.

Ne mélangez pas texte, design, logique tarifaire, paiement et publication dans une seule demande.

Cas 2 : documentation interne

Lis docs/onboarding/ et crée docs/onboarding/day-one-checklist.md.

Règles :
- Ne supprime aucun document existant.
- Explique les termes techniques à leur première apparition.
- Garde les points incertains sous "À confirmer".
- Termine par trois questions à poser aux RH ou à l'IT.

Pour aller plus loin, consultez la génération de documentation avec Claude Code.

Cas 3 : CSV et tableurs

Travaillez d’abord sur des données d’exemple avant d’utiliser des données clients réelles.

date,customer,plan,status,amount
2026-06-01,Acme,Standard,open,12000
2026-06-01,Northwind,Pro,closed,30000
2026-06-02,Contoso,Standard,open,12000

Inspecte data/inquiries.csv et crée un script d'extraction sûr.

Règles :
- Commence par afficher seulement les noms de colonnes et le nombre de lignes.
- Arrête-toi si une colonne ressemble à une donnée personnelle.
- Crée scripts/open-inquiries.mjs.
- node scripts/open-inquiries.mjs doit produire output/open-inquiries.csv.
- Indique le nombre de lignes extraites.

Pour les tableurs, voir l’automatisation spreadsheet avec Claude Code.

Cas 4 : automatisation métier

Avant d’automatiser, créez une procédure humaine claire.

Crée docs/daily-ops-checklist.md pour la routine opérationnelle de 9 h.

Entrées :
- Vérifier les demandes clients non résolues.
- Consulter le chiffre d'affaires d'hier.
- Vérifier les alertes d'erreur.
- Publier la priorité du jour dans Slack.

Sortie :
- Checklist étape par étape.
- Durée estimée.
- Ce qui peut être automatisé.
- Ce qui demande un jugement humain.
- Plan de retour arrière en cas d'échec.

Pour passer aux scripts, lisez les exemples d’automatisation de workflow.

Risques fréquents

Risque	Problème possible	Réponse sûre
« Corrige tout »	Trop de changements à relire	Un fichier, un objectif
Lire .env	Secrets exposés	Bloquer et demander conseil
Autoriser git push	Changement publié sans revue	Publication manuelle
Données clients réelles	Risque de confidentialité	Tester sur échantillon
Pas de preview	Erreur visible en production	Build, test, vérification visuelle
Relancer une erreur	Le même échec revient	Demander l’explication

Arrêtez-vous si la tâche parle de suppression, publication, paiement, connexion, données personnelles, contrats ou production.

Checklist quotidienne

Moment	Vérification
Début	Définir une seule tâche à terminer
Inspection	Dire « ne modifie pas encore »
Avant édition	Confirmer les fichiers ciblés
Approval	Lire l’outil et la commande
Après édition	Demander un résumé du diff
Avant partage	Vérifier que rien n’a été publié, envoyé, supprimé ou déployé
En cas de doute	Envoyer diff et question à un ingénieur

Formation et conseil

ClaudeCodeLab accompagne les équipes non techniques : prompts d’équipe, réglages de permissions, règles de revue, premières automatisations pour pages web, FAQ, rapports CSV et documentation.

Le meilleur premier projet est petit, répétable et facile à vérifier. C’est là que l’équipe apprend à demander, relire et s’arrêter.

Résultat vérifié

J’ai testé cette méthode sur trois tâches : correction de texte web, checklist d’onboarding et extraction CSV. Les meilleurs résultats venaient des consignes « ne modifie pas encore », « pose les questions d’abord » et « sépare les tâches risquées ». Sans elles, le diff devenait trop large pour une revue non technique.