01Méthode · Claude Code
Application interne avec Claude Code : méthode, limites et maintenance
Claude Code permet de livrer une application interne de PME en quelques semaines, à une condition : rien ne part en production sans un test capable d'échouer, vérifié par une machine tierce et relu. Voici la méthode que nous appliquons à nos propres logiciels comme à ceux de nos clients, ses limites, et ce que devient l'application après la livraison.
- Livraison
- 4-8 semaines
- Budget
- 5-20 k€
- Avis Google
- 4,9★
- Missions
- 128+
- Livraison moyenne
- 4-8 semaines
- Plus rapide qu'une ESN
- 3×
- Garantie correction bugs
- 30 j
01En bref
La réponse en une phrase
Une application interne codée avec Claude Code est aussi solide qu'une autre si chaque comportement est prouvé par un test écrit avant le code, si le verdict vient d'une machine tierce et si un humain garde les décisions de produit et de sécurité.
Mis à jour le 13 octobre 2026.
Claude Code est l'outil d'Anthropic qui permet à un modèle d'IA de lire un dépôt de code, d'écrire des fichiers et de lancer des commandes, sous la supervision d'un développeur. C'est une façon de pratiquer ce qu'on appelle le vibe coding en entreprise. L'outil accélère l'écriture du code ; il ne dit rien de sa qualité. La qualité vient du cadre dans lequel on le fait travailler, décrit ci-dessous.
02La méthode
Six règles pour qu'un agent de code livre du logiciel fiable
Ce sont les règles écrites qui encadrent nos projets avec intégration continue. Elles valent quel que soit l'outil d'IA utilisé.
1. Une seule commande de vérification
Lint, types, tests unitaires, d'intégration et de bout en bout, audit des dépendances : tout passe par une commande unique. L'agent la lance pendant qu'il code, l'intégration continue ne fait que l'appeler.
2. Le verdict vient d'une machine tierce
Chaque modification est rejouée sur une machine d'intégration continue. « Ça marche chez moi », dit par un agent, n'est pas une preuve : la fusion n'a lieu que si tous les contrôles sont verts.
3. Le testeur n'est pas le codeur
Un agent séparé écrit les tests à partir des seuls critères d'acceptation et les voit échouer. L'agent qui code n'a pas le droit de les affaiblir (test sauté, assertion retirée, valeur en dur).
4. Une preuve proportionnée au risque
Droits d'accès, argent, documents légaux, envois : tests sur une vraie base, couverture du code modifié d'au moins 90 %, test de mutation d'au moins 70 %. Ailleurs, un plancher de couverture qui ne recule pas.
5. Une base neuve à chaque test
Les tests tournent sur une base recréée de zéro, jamais sur celle que sert l'application. Un test qui manque d'un secret échoue, il ne se saute pas.
6. Revue, puis contrôle de la production
Relecture du code, revue de sécurité bloquante et passe de simplification avant fusion. Après la mise en ligne, contrôle de la version servie et retour arrière immédiat si quelque chose casse.
03Les limites
Ce que Claude Code fait bien, ce qu'il fait mal
Il fait bien
- les écrans, formulaires et listes qui se ressemblent ;
- les requêtes SQL et les migrations de base de données additives ;
- les tests, quand les critères d'acceptation sont clairs ;
- les montées de version, avec la batterie de tests comme filet ;
- la documentation du code qu'il vient d'écrire.
Il fait mal
- deviner un besoin flou : il comble les trous par des suppositions ;
- prouver son propre travail : il peut écrire un test qui passe toujours ;
- connaître vos règles non écrites (exceptions, habitudes, cas clients) ;
- parfois, appeler une fonction ou une option qui n'existe pas, que les types et les tests arrêtent ;
- trancher : produit, sécurité et arbitrages restent des décisions humaines.
Conséquence pratique : le temps gagné sur l'écriture du code est réinvesti dans le cadrage et les critères d'acceptation. Un projet mal cadré reste un projet mal cadré, plus vite.
04Dette technique
D'où vient la dette technique, et comment on l'évite
La dette technique, c'est le code que plus personne n'ose toucher : dupliqué, sans tests, avec des dépendances jamais mises à jour. Un agent de code peut en produire très vite, parce qu'il préfère ajouter que réorganiser. Quatre habitudes la contiennent :
- des technologies standard (TypeScript, Next.js, Postgres), sans framework maison ;
- une passe de simplification à comportement inchangé avant chaque fusion ;
- l'audit des dépendances dans la commande de vérification, pas « quand on y pense » ;
- la documentation dans le dépôt, au même endroit que le code.
Les autres garde-fous (relecture, données de test, responsabilité) sont détaillés dans le vibe coding est-il fiable pour une application d'entreprise.
05Maintenance
Ce que devient l'application après la livraison
Le code est livré dans un dépôt qui vous appartient, avec sa batterie de tests et son intégration continue. Chaque évolution, faite par nous, par un autre développeur ou par un agent, repasse par la même vérification : c'est ce qui rend la maintenance prévisible.
Exemple réel : fin septembre 2026, nous avons monté la version de Next.js de cinq de nos sites le même jour. Sans tests, c'est une opération qu'on repousse ; avec eux, c'est une tâche de routine. Les formules de maintenance et d'hébergement sont sur la page tarifs.
06Exemple réel
Nos propres logiciels, développés de cette façon
Nos logiciels en ligne, dont kaliio.fr (conformité Qualiopi des organismes de formation), et les sites du groupe, dont celui-ci, sont développés avec Claude Code dans ce cadre : aucune modification n'y est fusionnée sans le verdict de l'intégration continue. Notre ERP interne, qui suit les clients, les devis et les factures de nos deux sociétés, est lui aussi codé avec Claude Code, avec une vérification locale plus légère : c'est un outil à un seul utilisateur, et nous en assumons la différence. Le détail est dans la réalisation ERP IAvarone Conseil.
Avant de choisir comment construire, vérifiez qu'il faut construire : un SaaS du marché suffit souvent. Le tableau de décision est dans application interne pour PME : sur mesure, SaaS ou no-code.
07FAQ
Les questions qui reviennent
01 : Fiabilité
Pas si la preuve vient des tests et non de l'outil. La fiabilité dépend de la méthode : des critères d'acceptation écrits avant le code, des tests capables d'échouer, un verdict rendu par une machine tierce et une revue humaine. Sans ce cadre, une application codée à la main n'est pas plus fiable.
Oui, c'est le piège principal : un test qui passe toujours. C'est pour cela que les tests sont écrits par un agent séparé, vus en échec avant le code, et que les zones critiques passent un test de mutation, qui vérifie que les tests détectent une erreur introduite volontairement.
02 : Après la livraison
Oui. Le code livré est du TypeScript et du SQL standards, documenté dans le dépôt, avec sa batterie de tests. N'importe quel développeur qui connaît Next.js et Postgres peut le reprendre, avec ou sans IA.
L'hébergement coûte quelques dizaines d'euros par mois. La maintenance est optionnelle et se choisit selon le périmètre : les fourchettes sont sur la page tarifs. Les mises à jour de dépendances passent par la même vérification que le reste du code.
Non. Le développement se fait sur des données synthétiques ou anonymisées, et les tests sur une base recréée à chaque exécution. Vos données réelles restent dans votre application.
08Prendre rendez-vous
Voir la méthode appliquée à votre outil
Venez avec l'outil interne que vous voulez construire ou reprendre. En 30 minutes de visio, on regarde ce qui doit être prouvé par des tests, ce qui relève de votre décision, et si le sur mesure est le bon choix.
Prochain créneau cette semaine
Une application interne fiable, livrée en quelques semaines ?
En visio, gratuit, sans engagement. Nous voyons si l'approche convient, ou je vous oriente ailleurs si le périmètre dépasse mon champ d'intervention.
Cadrage offert · 30 min en visio
Prendre rendez-vous