Le manifeste SliceOps

L'industrie a passé deux ans à débattre de savoir si l'IA remplace les développeurs. C'est la mauvaise question. La bonne est structurelle : à quoi ressemble l'ingénierie logicielle quand l'essentiel de la frappe est fait par des agents et l'essentiel du jugement par des humains ?

Les sprints supposent des humains tenus par des standups et des engagements de deux semaines. Les agents n'ont pas ces contraintes. Un slice prend cinq millions de tokens et dix minutes, le suivant en prend soixante millions et une journée. Enfermer cette vélocité dans des rituels conçus pour des employés de bureau est, en silence, un anti-pattern.

Le parallélisme multi-agents brise une seconde hypothèse : qu'un développeur touche une branche à la fois. Lancez une douzaine d'agents contre un même dépôt et, sans dépendances explicites ni compteurs de décision atomiques, le parallélisme qui devrait composer devient le parallélisme qui entre en conflit.

SliceOps est le framework ouvert et plan d'audit pour l'ingénierie logicielle AI-first. Ce n'est pas un éditeur de code. Ce n'est pas un agent autonome. Ce n'est pas un outil de qualité de code ni une plateforme de compliance a posteriori. C'est la couche qui se place au-dessus de toutes ces solutions.

Si Cursor, Claude Code, Devin et Copilot sont les runtimes des agents, SliceOps est ce qui tourne au-dessus : le ledger de décisions, l'unité d'atomicité, le graphe de dépendances et le plan d'audit qui rend toute la stack lisible pour un relecteur humain, un auditeur réglementaire ou le prochain agent qui arrive à froid.

Il est ouvert par conception. Le framework vit en markdown, les outils en Python et TypeScript, les règles en CI. Aucun vendor lock-in. N'importe qui peut l'adopter. N'importe qui peut le forker.

C'est là que SliceOps diffère le plus de tout le reste. SonarQube audite le code. Les outils de runtime auditent l'exécution. Vanta et Drata auditent l'entreprise, après coup. Credo AI audite les modèles. Tout cela est nécessaire. Aucun n'audite le plan au-dessus du code.

Ce plan, c'est l'intégrité des décisions architecturales : le slice était-il cohérent avec la spec de la section ? La spec était-elle cohérente avec le plan ? Les décisions citées étaient-elles celles qui régissent réellement le changement ? Une contradiction cross-slice est-elle apparue, qu'il faut résoudre ?

C'est le plan qui décide si un logiciel produit par des agents à grande échelle est un système maintenable ou une bombe à dette. C'est le plan que personne d'autre ne surveille, et celui que SliceOps met dans l'éditeur du développeur plutôt que dans un dashboard de compliance.

L'ingénierie logicielle classique gardait le contexte dans la tête des gens. Les agents d'IA sont sans mémoire, chaque session démarre à froid. SliceOps traite donc le corpus lui-même comme leur contexte partagé : fondations, décisions, architecture et spécifications deviennent une seule source de vérité gouvernée, routée vers chaque agent à la demande et tenue cohérente entre tous.

SliceOps appelle cela la Discipline de contexte, et c'est la partie dont aucun SDLC classique n'a jamais eu besoin : les humains portaient le contexte dans leur tête ; les agents sans mémoire ne le peuvent pas. Sans elle, les slices atomiques, le plan d'audit et l'apprentissage récursif se fracturent, parce que chaque agent travaillerait à partir d'une image différente et à la dérive du système.

Il y a une expression à mettre à la retraite (le compliance theater) et une à installer à sa place : compliance-ready par construction.

Quand vous adoptez SliceOps, chaque décision architecturale est un registre qui correspond à un contrôle ISO 42001, un critère SOC 2 ou une exigence de documentation de l'EU AI Act. Vous n'écrivez pas ces documents parce qu'un auditeur arrive. Vous les écrivez parce qu'ils sont le framework. Quand l'auditeur arrive, vous exportez le ledger et c'est terminé.

L'Article 50 de l'EU AI Act entre en vigueur le 2 août 2026. ISO 42001 est déjà un gate d'achat. La feuille de route de conformité n'est pas un chantier à part : c'est ce qui arrive quand vous livrez des slices.

SliceOps n'a pas été conçu lors d'une séance de whiteboard. Il a été extrait de la réalité de production de la construction de Datta (un produit cross-industry pour marchés régulés) avec une petite équipe et une flotte d'agents Claude Code, mesuré en temps d'exécution, pas en temps de calendrier.

Plus de 800 Decision Records, flat-numbered et lifecycle-tracked. Un bloc livré en quatre jours calendaires à travers neuf slices atomiques, sous son forecast de tokens, avec 41 décisions architecturales capturées. Jusqu'à treize agents en parallèle contre un même dépôt. Un multiplicateur d'efficacité de 2,5×, mesuré face à la consommation équivalente de tokens via API.

C'est du dogfooding. SliceOps est le système auquel je fais assez confiance pour y miser un spin-off bancaire régulé.

Essayez le framework sur un seul slice de votre prochain sprint. Déclarez un decision record pour un choix que vous auriez fait de façon informelle. Lancez un forecast au début de votre prochain bloc et une rétrospective à la fin. Voyez ce que les artefacts donnent, et ce que vos agents en font quand ils les lisent.

Construisez avec discipline. Auditez vos décisions. Traitez vos agents comme les ingénieurs industriels traitent leurs machines : avec télémétrie, rétrospective et l'hypothèse que ce qui n'est pas mesuré finira par casser.