Aller au contenu
FT Lab par FTC · code encadré Nous contacter

L’IA écrit le code. Le cadre et l’humain décident.

Chez FT Lab, l’IA ne code jamais librement. Elle travaille dans un cadre écrit, versionné avec chaque projet, et chaque ligne passe par des contrôles automatiques puis par la validation d’un développeur.

Voir ce que cela change pour vous Voir le dispositif technique
Le parcours de chaque modification, de la règle écrite à la production
  1. Règles écritescadre versionné, lu à chaque session
  2. Plan validé par un humaindécision humaine
  3. Lint, typage strict, testscontrôle automatique
  4. Revue humaine du codedécision humaine
  5. Quatre environnements successifs
    1. DEV
    2. PREPROD
    3. DEMO
    4. APP
    La mise en production est déclenchée par un humain.
  • contrôle automatique
  • décision humaine

Le principe

L’IA accélère l’écriture du code. Elle ne remplace ni la méthode ni la responsabilité humaine.

  1. 01

    Un kit de règles de codage

    L’agent le lit à chaque session. Il couvre la qualité, la sécurité, les API, le back, le front, le mobile et le déploiement.

  2. 02

    Un référentiel de règles MySQL

    Il impose le nommage, la structure, l’intégrité et la traçabilité de chaque table de la base de données.

  3. 03

    Des contrôles indépendants de l’IA

    Lint, typage strict, tests et revue humaine. Ils ne dépendent pas de la bonne volonté de l’IA.

Ce que cela change pour vous

Choisissez votre profil. Les mêmes règles, vues depuis votre rôle.

Dirigeant : cinq garanties

  • Un humain décide toujours

    Pour toute tâche non triviale, l’IA propose un plan et attend sa validation. Elle ne déclenche jamais une mise en production.

  • Les mêmes règles pour tout le monde

    Les standards sont écrits et appliqués à chaque session. Un développeur seul peut les oublier un vendredi soir, le cadre non.

  • Vos données sont protégées

    L’IA n’a accès ni aux mots de passe, ni aux clés, ni aux configurations sensibles. Elle ne peut ni supprimer de données ni modifier la base de production.

  • Tout est traçable

    Chaque modification est tracée dans l’historique du code. Chaque enregistrement garde la date et l’auteur de sa création et de sa dernière modification.

  • Rien n’arrive en production sans tests

    Quatre environnements successifs précèdent vos utilisateurs.

DSI ou CTO : un cadre versionné comme le code

Le cadre est du code comme un autre : des fichiers Markdown versionnés dans chaque dépôt, relus et amendés par pull request.

  • Instructions de projet

    Un fichier CLAUDE.md fixe la méthode de travail et les interdits.

  • Règles par domaine

    Des fichiers dans .claude/rules/, chargés selon les fichiers touchés.

  • Référentiel MySQL

    Nommage, clés, colonnes d’audit, contraintes et migrations.

  • Contrôles automatiques

    Lint, typage strict et tests, puis revue humaine avant fusion.

Lire le dispositif couche par couche

Équipe technique : la méthode en six étapes

  1. Cadrer

    Décrire la tâche en User Story avec son contexte, et demander un plan.

  2. Valider le plan

    C’est ici qu’on écarte les mauvaises pistes.

  3. Laisser coder par petits incréments

    Une tâche, un périmètre, un commit.

  4. Vérifier

    Lint, typecheck, tests, puis relecture du diff comme celui d’un collègue.

  5. Lire le résumé final

    Les choix faits et les points à vérifier avant fusion.

  6. Faire évoluer les règles

    Une erreur répétée devient une règle écrite.

Investisseur ou partenaire : un actif mieux maîtrisé

  • Vitesse maîtrisée

    L’IA accélère l’écriture, les contrôles et la revue gardent la qualité constante.

  • Savoir-faire capitalisé

    Les règles sont écrites, versionnées et enrichies à chaque incident.

  • Dépendance aux personnes réduite

    La méthode est dans les dépôts, pas seulement dans la tête d’un développeur.

  • Due diligence facilitée

    Conventions, historique et traçabilité sont consultables dans le code et la base.

  • Croissance sans explosion des coûts

    Le cadre tient quand l’équipe ou le produit grandissent.

  • Sécurité et conformité

    Règles OWASP, aucun accès de l’IA aux secrets ni à la production.

Le dispositif technique, couche par couche

Quatre couches, versionnées avec chaque projet. Chacune ferme une porte que la précédente laisse entrouverte.

  1. couche 1

    Instructions de projet

    CLAUDE.md
    • Lire le code existant et reprendre ses conventions.
    • Faire des changements minimaux.
    • Lancer lint, typecheck et tests après chaque modification.
    • Ne jamais désactiver les tests, le lint ou le typage.
    • Ne jamais inventer une API, une option ou un champ.
    • Aucun accès aux fichiers .env, aux secrets ni aux migrations déjà appliquées. Aucune commande destructive sans accord.
    • Justifier toute nouvelle dépendance et la faire valider.
    • Rendre un résumé final à chaque tâche.
  2. couche 2

    Règles par domaine

    .claude/rules/
    • Qualité et sécurité toujours chargées.
    • API, back, front, mobile et infra chargées selon les fichiers touchés.
    • Appuyées sur Clean Code, SOLID, KISS, YAGNI et OWASP.
    • Migrations compatibles avec la version N-1.
  3. couche 3

    Règles base de données MySQL

    référentiel MySQL
    • Tables préfixées tbl_, clé Id en BIGINT auto-incrémentée.
    • Colonnes d’audit CreationDate, CreationUserId, ModificationDate, ModificationUserId.
    • InnoDB, clés étrangères et contraintes portées par la base.
    • DECIMAL pour les montants, dates en UTC.
    • Migrations versionnées, jamais réécrites. Une colonne se supprime en plusieurs étapes.
    • Aucun script direct en production. Ordre imposé : DEV, PREPROD, DEMO, APP.
  4. couche 4

    Contrôles automatiques

    avant chaque fusion
    • Lint
    • Typage strict
    • Tests
    • Revue humaine avant fusion

Les craintes courantes, et ce qui y répond

Chaque crainte a une règle écrite et un contrôle qui la vérifie.

Craintes courantes, réponses du cadre et contrôles associés
Crainte Réponse du cadre Contrôle
L’IA invente des fonctions ou des champs Interdiction d’inventer, vérification dans le code, le schéma ou la documentation Typecheck, tests, revue
Failles de sécurité Règles OWASP, requêtes paramétrées, aucun accès aux secrets Revue, lint sécurité
Suppression ou corruption de données Aucune commande destructive sans accord, aucun script direct en production Validation humaine, DEV → PREPROD → DEMO → APP
Code hétérogène Conventions écrites par domaine, reprise de l’existant Lint, revue
Base incohérente Nommage, clé Id, colonnes d’audit et contraintes imposés Revue des migrations
Tests contournés Interdiction de désactiver les tests, le lint ou le typage Revue du diff
Dépendances douteuses Justification et validation de toute dépendance Revue
Perte de maîtrise Plan validé, petits incréments, résumé final Un humain décide à chaque étape

Faites défiler le tableau horizontalement pour voir les trois colonnes.

Nos engagements, et leurs limites

Nos engagements

  • Aucune mise en production sans validation humaine.
  • Aucun accès de l’IA aux secrets ni aux données de production.
  • Nos règles sont consultables sur demande.
  • Une traçabilité complète, dans le code comme dans la base.

Ce que nous ne prétendons pas

  • L’IA peut encore se tromper. Les tests et la revue sont là pour le vérifier.
  • Nos règles sont une synthèse de bonnes pratiques, pas une certification.
  • Le kit n’est pas figé. Il évolue à chaque incident.

Parlons de votre projet

Un projet à lancer, une question sur le cadre, ou l’envie de consulter nos règles ? Écrivez‑nous.

Écrire à frederic@ftlab.fr