Tu as déjà vécu ce moment absurde : tu vends du logiciel, tu déploies en CI/CD, tu fais du Infrastructure-as-Code… et quand il faut expliquer “comment marche la boîte”, tu sors un PDF poussiéreux, trois Google Docs et l’info “dans la tête de Sophie”.
Daniel Rothmann raconte exactement ça pendant un audit ISO 27001 : une entreprise ultra-digitalisée, mais dont le cœur (politiques, procédures, structure) reste géré comme du papier numérique. Résultat : des centaines d’heures humaines à “prouver” ce qui existe déjà dans les systèmes. Source : Company as Code (42futures, 25 fév. 2025).
Ce billet te propose une version actionnable du concept Company as Code : comment modéliser ton organisation comme un système déclaratif, versionné, testable, connecté à tes outils (HRIS, CRM, ticketing, IAM), et prêt pour l’automatisation par agents IA.
Company as Code, c’est quoi (sans poésie)
Company as Code (ou Business-as-Code) = décrire ta boîte avec une représentation formelle (souvent un DSL + des fichiers YAML/JSON/TS), stockée dans Git, avec :
- Versioning : chaque changement d’organisation/politique = un commit, une PR, un historique.
- Tests : tu peux vérifier automatiquement des règles (séparation des rôles, validations, accès, conformité).
- Déploiement : tu “appliques” le changement vers les systèmes (Notion/Confluence, Okta, Slack, Jira, HubSpot, etc.).
- Observabilité : tu interroges l’org comme une base de données (“qui peut approuver un remboursement > 5k ?”).
L’idée n’est pas de “coder la culture”. L’idée est de coder ce qui doit être explicite : responsabilités, règles, processus, contrôles.
- Infrastructure-as-Code pour les serveurs,
- GitOps pour les déploiements,
- Policy-as-Code pour la sécurité.
Rothmann pose la question qui pique : si on exige que la donnée opérationnelle soit riche, pourquoi accepte-t-on que la donnée organisationnelle soit pauvre ? (42futures).
Pourquoi maintenant : l’IA et le low-code rendent ça inévitable
Deux tendances rendent Company as Code beaucoup plus réaliste en 2026 qu’en 2016 :
- Gartner projette que 75% des nouvelles applications d’entreprise seront construites en low-code/no-code d’ici 2026 (chiffre repris dans des synthèses industrie).
- Et 87% des développeurs en entreprise utilisent déjà du low-code pour certaines tâches (DreamFactory, stats agrégées).
Traduction : tes process ne vivent plus dans un ERP monolithique. Ils vivent dans des configs et des automatisations dispersées.
2) La génération de code et les agents Gartner anticipe qu’en 2028, 40% des nouveaux logiciels d’entreprise seront créés via des techniques de génération à partir de prompts (cité dans un article WSJ sur le “vibe coding”).
Traduction : écrire/maintenir un “modèle d’entreprise” en code devient plus accessible, même pour des équipes non-tech, si tu mets de bons garde-fous.
Le problème réel : ton organisation est déjà du code… mais en mode spaghetti
Aujourd’hui, ta boîte est déjà “programmée”, juste pas proprement :
- Les règles d’accès sont dans Google Workspace/Okta.
- Les workflows sont dans Zapier/Make/n8n.
- Les pipelines de vente sont dans HubSpot/Salesforce.
- Le support est dans Zendesk/Intercom/Jira Service Management.
- La compta est dans Pennylane/Xero/QuickBooks.
Tout ça a des API. Tout ça est modifiable. Et pourtant, la source de vérité est souvent un doc statique.
- Tu ne sais pas vraiment “qui décide quoi”.
- Les nouveaux mettent 3 mois à comprendre.
- Chaque audit devient un chantier.
- Tu casses des process sans le voir (effet domino).
Company as Code vise à remettre une architecture sur ce bazar.
Ce que tu gagnes (concrètement)
1) Moins de temps perdu en audits et conformité Rothmann parle de centaines d’heures supplémentaires liées à la collecte de preuves, la mise à jour de wording, les revues, etc. (42futures).
- des preuves automatiques (logs, exports, snapshots) attachées à des contrôles,
- des checks continus (ex : “tout accès admin doit avoir MFA + justification”),
- des PR qui déclenchent une checklist de conformité.
2) Onboarding accéléré Au lieu de “demande à Pierre”, tu donnes : - un graphe des équipes/rôles, - des runbooks versionnés, - des workflows reproductibles.
3) Moins de dépendance aux “héros” Quand l’organisation est implicite, elle dépend des personnes. Quand elle est codifiée, elle dépend d’un système revu et versionné.
4) Un vrai levier d’automatisation par IA Un agent IA est nul avec des PDFs contradictoires. Il est bon avec : - des règles explicites, - des permissions claires, - des événements et des API.
Company as Code devient le “contrat” qui empêche l’agent de faire n’importe quoi.
À quoi ressemble une implémentation simple (MVP)
Pas besoin d’inventer un langage chelou dès le jour 1. Un MVP réaliste pour une PME/scale-up :
1) Un repo “company”
- /org/teams.yaml (équipes, owners, missions)
- /org/roles.yaml (rôles + responsabilités)
- /policies/ (sécurité, achats, accès, RH)
- /processes/ (onboarding, remboursement, incident)
- /controls/iso27001/ (contrôles + preuves attendues)
2) Un schéma + linter - JSON Schema / OpenAPI pour valider la structure - un linter pour empêcher les incohérences
3) Des tests (oui, des tests) Exemples : - “Tout processus de paiement > 10k nécessite 2 approbateurs de départements différents.” - “Aucun freelance ne peut avoir accès à prod + facturation.” - “Chaque équipe a un owner et un backup.”
4) Un pipeline GitOps “apply” Quand une PR est mergée : - mise à jour automatique d’une page Notion/Confluence, - sync des groupes Slack/Google/Okta, - création/MAJ de tickets Jira, - génération d’un “audit pack” (exports datés).
C’est exactement l’intuition “appliquer DevOps à BizOps” que pousse aussi Salto avec son approche “Company-as-Code” et leur langage déclaratif NaCl pour versionner les configurations d’outils business (Salto, billet Jan–Fév 2026).
Cas d’usage qui parlent aux entrepreneurs (pas aux consultants)
Cas 1 — Remboursements & achats Problème : tout le monde peut faire passer une dépense “en douce”, ou c’est bloqué par une seule personne.
- règles déclaratives (seuils, approbateurs, exceptions),
- tests (pas d’approbateur unique sur gros montants),
- déploiement vers ton outil (Spendesk/Pennylane + Slack approvals).
Cas 2 — Accès aux données (RGPD/ISO/SOC2) Problème : tu ne sais plus qui a accès à quoi.
- mapping “rôle → systèmes → permissions”,
- revue automatique trimestrielle,
- preuve exportable.
Cas 3 — Sales ops (CRM) Problème : ton pipeline HubSpot/Salesforce dérive, les champs changent, les automatisations cassent.
- versionnage des configs,
- PR pour changer un champ critique,
- rollback si ça casse.
Cas 4 — Incident management Problème : quand ça brûle, tu improvises.
- runbooks versionnés,
- escalade claire (qui est on-call, qui valide le post-mortem),
- génération automatique du rapport.
Les pièges (et comment ne pas te tirer une balle)
Piège 1 : vouloir tout formaliser Si tu “codes” trop, tu crées une bureaucratie… en YAML.
Règle : code uniquement ce qui doit être stable, auditable, ou automatisable.
Piège 2 : confondre source de vérité et interface Notion est une bonne interface. Git est une bonne source de vérité.
Tu peux publier vers Notion, mais éviter que Notion soit l’endroit où “la vérité change” sans contrôle.
Piège 3 : sécurité et droits d’écriture Le repo “company” doit être protégé comme un repo prod : - PR obligatoires, - reviewers, - logs, - signatures si nécessaire.
Piège 4 : l’illusion “l’IA va gérer la boîte” Non. L’IA exécute. Les humains gouvernent.
Le bon modèle, c’est : agents + humain dans la boucle + règles testées.
Une roadmap en 30 jours pour démarrer
- liste 10 décisions/process critiques (paiements, accès, pricing, support, recrutement)
- choisis 1 périmètre (ex : accès + onboarding)
- crée le repo + schéma
- écris 5 règles non négociables (tests)
- connecte 2 systèmes via API (ex : Okta/Google Workspace + Slack)
- génère une doc publiée automatiquement
- ajoute un “audit pack” automatique
- mesure : temps d’onboarding, incidents d’accès, temps passé en conformité
Tu itères ensuite. Pragmatique, pas dogmatique.
Bottom line
Company as Code, ce n’est pas un délire d’ingénieur. C’est une réponse logique à un fait : ton business est déjà un système distribué de SaaS et d’automatisations. Tant que ta structure et tes règles restent des documents statiques, tu vas payer une taxe invisible : lenteur, erreurs, audits pénibles, dépendance aux personnes.
Le move intelligent en 2026 : mettre une source de vérité versionnée au centre, brancher tes outils autour, et laisser l’IA automatiser l’exécution sous contrôle.
Tu veux automatiser tes opérations avec l'IA ? Réserve un call de 15 min pour en discuter.