Le CRM est dans git
Chez nous, le CRM est dans git. Le calendrier éditorial est dans git. Le plan stratégique est dans git. Les modules de formation sont dans git. Les briefs prospect, les comptes rendus de RDV, la narrative bible, les decks commerciaux — tout est en markdown versionné, dans un dépôt git.
Ce n'est pas une lubie de geek. C'est la couche d'infrastructure qui rend Jarvis et Donna possibles. Sans elle, nos agents IA seraient ce que sont 94 % des déploiements IA aujourd'hui d'après le State of AI 2025 de McKinsey : impressionnants en démo, inertes en production. Avec elle, ils opèrent. Vraiment. Sur six mois de test interne, Donna rend 2 à 3 heures par jour à un dirigeant parce qu'elle lit, écrit et raisonne sur des fichiers que git horodate à chaque modification.
Cet article raconte ce qu'est la méthode AIDC repository-first que nous appliquons à The Shift AI, pourquoi elle est nécessaire pour déployer sérieusement des agents IA en entreprise, et pourquoi nous l'installons aussi chez nos clients.
Ce qu'est repository-first, concrètement
Pas de théorie. La cartographie réelle.
Notre dépôt contient :
crm/prospects/— une fiche.mdpar prospect. Contexte de l'entreprise, interlocuteurs, historique des échanges, stage du deal, prochaines actions. Une fiche par client, une fiche par dossier en cours.crm/clients/— la même chose pour les clients signés. Mission en cours, livrables, jalons, facturation..bsg/CALENDAR.md— le calendrier éditorial complet du trimestre. Un thème par ligne, une date, un canal, un statut, un responsable..bsg/PLAN.md— le plan stratégique de The Shift AI. Objectifs trimestriels, jalons produits, priorités commerciales. Versionné. Diffé entre deux semaines. Lisible.brand/NARRATIVE.md— la narrative bible. Voix, registre, messages clés, positionnement. Ce que dit Guillaume DUMAS, ce qu'il ne dit jamais.formations/— chaque module de formation IA, écrit en markdown, conforme Qualiopi, prêt à être lu par un agent qui prépare une session.content/blog/— les articles. Celui-ci, par exemple. Frontmatter YAML, corps markdown, métadonnées SEO, le tout dans un fichier de 30 ko que git suit caractère par caractère.comms/press-kit/— les decks prospect, générés via Marp depuis du markdown vers du PDF. Pas une slide manuelle.
Tout est texte. Tout est diffable. Tout est versionné. Tout est interrogeable par un agent IA aussi facilement que par un grep lancé depuis un terminal.
Pourquoi c'est nécessaire pour des agents IA sérieux
Un agent IA n'est pas un copilote conversationnel. Un agent IA est un programme autonome qui agit dans un système. Pour qu'il agisse, il a besoin d'un état persistant interrogeable — c'est-à-dire : un endroit où il peut lire ce qui est vrai aujourd'hui, écrire ce qu'il vient de faire, et où la trace de ses modifications est conservée pour que son successeur (ou un humain) comprenne le contexte.
La plupart des déploiements IA ratent à cet endroit précis. Stanford Digital Economy Lab a analysé 51 déploiements d'agents IA en entreprise en 2025. Le motif d'échec dominant n'est pas le modèle. Ce n'est pas la qualité du prompt. C'est l'absence de mémoire structurée que l'agent peut lire et modifier. L'IA est branchée sur Notion, sur Salesforce, sur Excel, sur SharePoint — quatre silos différents, quatre API différentes, quatre formats fermés, quatre couches d'authentification. L'agent passe 80 % de son temps à essayer de comprendre où regarder. Il ne fait jamais le travail.
Repository-first résout ça en une décision : un seul dépôt git, en markdown, et c'est la source de vérité. L'agent ouvre un fichier. Il le lit. Il le modifie. Il commit. La modification est tracée, signée, attribuable. Le prochain agent qui passe sait exactement ce qui s'est passé. McKinsey mesure +71 % de productivité chez les déploiements agentiques qui réussissent. Ces 71 %, ils ne viennent pas d'un meilleur modèle. Ils viennent d'une meilleure plomberie. Notre plomberie, c'est git.
Ce que ça permet : Jarvis et Donna en preuve
Jarvis est notre usine logicielle. Il génère 80 % du code que nous livrons à nos clients. Comment ? Il lit les specs fonctionnelles écrites en markdown dans le dépôt du projet, il croise avec les conventions techniques décrites dans un CLAUDE.md, il écrit le code, il ouvre une pull request, il attend la revue humaine. Pas de magie. Pas de prompt à 4 000 lignes. Juste : des fichiers markdown clairs en entrée, du code propre en sortie, et git pour tout suivre.
Donna est notre assistante de direction. Avant chaque rendez-vous, elle prépare un brief de deux pages. Comment ? Elle ouvre la fiche prospect dans crm/prospects/<slug>.md, elle lit l'historique des échanges, elle relit le dernier compte rendu, elle agrège les signaux faibles repérés dans la presse, elle produit le brief. Sans le CRM repository-first, Donna ne fait rien d'utile. Avec, elle décharge un dirigeant de 2 à 3 heures par jour mesurées sur six mois — chiffre que nous avons publié dans le retour d'expérience Donna.
Même logique chez MFA, notre cas d'école industriel. L'agent SAV s'appuie sur 400 documents techniques couvrant 14 marques, structurés et interrogeables. Un nouveau document devient utilisable par l'agent en 48 heures. Les 3 heures par jour que chaque membre de l'équipe SAV passait à chercher la bonne référence dans des PDF dispersés sont désormais libérées. Pas parce qu'on a remplacé l'équipe. Parce que la connaissance MFA est dans une structure interrogeable par un agent, pas dans un dossier réseau.
L'opposition au modèle classique
Notion, Salesforce, Excel, SharePoint, Confluence — ce sont des outils excellents pour des humains. Ce sont des outils catastrophiques pour des agents.
Notion vs git. Notion stocke en base propriétaire, l'agent doit passer par une API rate-limitée, le diff entre deux versions est invisible. Git stocke en texte, l'agent ouvre le fichier, le diff est natif.
Salesforce vs markdown. Salesforce verrouille votre CRM dans un schéma rigide, facturé au siège, avec un export que personne ne fait. Le markdown est lisible dans n'importe quel éditeur, gratuit, portable.
Excel vs CALENDAR.md. Excel stocke votre calendrier éditorial dans une grille fermée, où le moindre script doit passer par une couche COM ou OpenXML. Un fichier markdown se lit en deux lignes de Python.
PowerPoint vs Marp. PowerPoint produit des binaires de 40 Mo non versionnables. Marp produit du markdown qui devient PDF en une commande, et chaque slide est diffable.
Ce n'est pas une querelle d'outils. C'est une question d'accessibilité aux agents IA. Tout ce qui n'est pas du texte versionné est, pour un agent, soit invisible, soit hors de portée, soit interrogeable au prix d'une intégration coûteuse qui se cassera à la prochaine migration.
Les bénéfices secondaires (qui ne sont pas si secondaires)
Repository-first, c'est aussi :
- Traçabilité totale.
git logrépond à la question « qui a modifié quoi, quand, pourquoi ». Sur la fiche d'un prospect, sur le PLAN.md, sur la fiche d'un module de formation. Auditable. - Reproductibilité. Un nouveau collaborateur clone le dépôt et a immédiatement l'état complet de l'entreprise. Pas d'onboarding à six semaines sur quatorze outils.
- Anti-lock-in. Si demain GitHub disparaît, nous changeons d'hébergeur en une commande. Les fichiers nous appartiennent. Ce sont des
.md. - Formats ouverts pour 30 ans. Le markdown a 22 ans. Le texte brut a 60 ans. Notre dépôt sera lisible en 2056. Votre base Salesforce de 2026 sera lisible en 2056 ? On ne parierait pas.
On installe la même méthode chez nos clients
Tout ce que vous venez de lire, nous l'installons chez nos clients. Quand nous livrons une mission, nous livrons le code, le dépôt GitHub, les comptes. Le client repart propriétaire. Il peut continuer seul, recruter un dev qui reprend le dépôt, faire évoluer ses agents IA. Aucun lock-in. Aucune dépendance à The Shift AI au-delà de ce qui est négocié.
MFA a aujourd'hui son dépôt, son agent SAV, ses 3 000 fichiers documentaires en markdown versionné. Si demain ils nous remercient, ils gardent l'usine. C'est le contraire du modèle SaaS classique. C'est ce qui rend la méthode AIDC reproductible.
Anaphore manifeste
Le CRM doit être dans git, parce qu'un agent IA doit pouvoir le lire.
Le calendrier doit être dans git, parce qu'un agent IA doit pouvoir le mettre à jour.
Le plan stratégique doit être dans git, parce qu'un agent IA doit pouvoir le challenger.
Les briefs commerciaux doivent être dans git, parce qu'un agent IA doit pouvoir les préparer la nuit pour vous, pendant que vous dormez.
Les modules de formation doivent être dans git, parce qu'un agent IA doit pouvoir les adapter à la session du lendemain matin.
Tout ce que vous ne mettez pas dans git, vous le retirez à vos agents IA. Et un agent IA sans état persistant interrogeable, c'est un copilote conversationnel. Pas un agent.
Conclusion
Repository-first n'est pas notre marketing. C'est notre infrastructure. C'est la couche que personne ne raconte parce qu'elle est technique, et que la plupart des cabinets conseil ne sauraient pas l'installer si on le leur demandait. C'est notre unfair advantage. Et c'est reproductible chez vous.
Dans cinq ans, votre entreprise sera AI Driven. Ou elle ne sera plus. AI Driven veut dire : vos agents IA opèrent sur vos données, en continu, avec mémoire et traçabilité. Et cela suppose une seule chose, en amont de tout le reste : que vos données soient interrogeables par des agents. Pas par des humains qui ouvrent un onglet Notion. Par des agents qui lisent des fichiers.
Vous voulez installer la méthode AIDC repository-first chez vous ? Parlons-en.
#AIDC #RepositoryFirst #Git #Markdown #IADrivenDevelopment
