Le Bolt, ou comment découper le travail quand l'IA code en minutes

Chez ConnectiveRx, éditeur américain de solutions d'accès aux traitements, les équipes ont livré en environ 24 heures un cas d'usage estimé à environ 180, en travaillant par « bolts »¹. Le Bolt est l'unité de travail d'AI-DLC, la méthode publiée par AWS en juillet 2025², présentée dans AI-DLC, le cycle d'AWS qui remplace le sprint par le Bolt. Il remplace le sprint de Scrum : là où une équipe s'engageait sur deux semaines, AWS raisonne en heures, parce qu'un agent écrit le code et les tests d'une fonctionnalité en quelques minutes.

Définition

Un Bolt est un petit morceau de travail que l'agent planifie, que l'équipe approuve, que l'agent code et teste, et que l'équipe valide, le tout en quelques heures, parfois quelques jours.

L'exemple : une application de réservation de salles

Exemple fictif : une équipe construit une application de réservation de salles de réunion. Pendant l'Inception, première phase d'AI-DLC, l'agent propose trois gros morceaux, qu'AWS appelle des Units of Work, et l'équipe valide ce découpage :

• la gestion des salles (créer une salle, sa capacité, son étage) ;
• les réservations (réserver un créneau, éviter les doublons) ;
• les notifications (prévenir par e-mail).

Une Unit ressemble à un epic en Scrum. Chacune se construit ensuite en un ou plusieurs Bolts. Les réservations dépendent des salles (on ne réserve pas une salle qui n'existe pas) ; les notifications, elles, peuvent avancer à côté.

Ce qui se passe pendant un Bolt

Prenons le Bolt « créer une réservation ».

1. L'agent écrit son plan. Tables à créer, écran à construire, règles (pas deux réservations sur le même créneau), tests à écrire. Il pose ses questions : faut-il gérer les réservations récurrentes ?
2. L'équipe répond et approuve. Trois à cinq personnes (métier, développement, QA) lisent le plan ensemble, tranchent les questions, corrigent. L'agent attend ce feu vert pour coder.
3. L'agent code. Il écrit le code et les tests prévus par le plan.
4. L'agent lance les tests. Il utilise la commande que l'équipe a choisie (par exemple pytest). Si elle échoue, il rend la main à l'équipe.
5. L'équipe regarde le résultat et valide. Le Bolt se termine sur quelque chose de visible : un écran qui fonctionne, un test vert.

Le cycle complet tient dans une séance de quelques heures. Chez ConnectiveRx, analystes métier, développeurs, QA et ingénieurs travaillaient ainsi en parallèle, avec l'éditeur Kiro d'AWS¹.

Le premier Bolt : un squelette qui marche

Pour une fonctionnalité, un MVP ou un POC, l'outil planifie en premier un Walking Skeleton, un « squelette qui marche » : la version la plus mince possible de l'application qui traverse toutes les couches³⁴.

Dans l'exemple, ce serait un écran minimal qui enregistre une réservation dans la base de données, et un test qui vérifie qu'elle y est bien. L'écran est laid, la fonctionnalité est pauvre, mais l'équipe sait que l'interface, le serveur, la base et les tests communiquent. L'outil affiche alors Verified with pytest (exit 0), c'est-à-dire « tests passés » (la commande affichée est celle que l'équipe a choisie).

Les autres Bolts attendent que l'équipe approuve ce squelette. Pour un correctif ou une refonte, l'outil ne planifie pas de squelette : l'application tourne déjà.

Ensuite, l'équipe règle la laisse de l'agent

Une fois le squelette validé, l'agent pose une seule question : comment continuer³⁴ ?

• « Continuer automatiquement » : l'agent enchaîne les Bolts suivants sans demander la permission à chaque étape. Il s'arrête quand même pour faire approuver chaque plan, et dès qu'un test échoue.
• « Revoir chaque point de contrôle » : l'agent s'arrête à la fin de chaque Bolt pour que l'équipe valide.

L'équipe accorde donc l'autonomie après avoir vu l'agent livrer quelque chose qui fonctionne, et tout échec lui rend la main. Le SDLC SFEIR applique la même règle à l'exécution autonome sous preuve.

Plusieurs Bolts en même temps

Dans l'exemple, les salles et les notifications ne dépendent pas l'une de l'autre. Si l'équipe a demandé l'exécution en essaim (swarm), l'outil d'AWS lance leurs Bolts en parallèle³⁵.

Chaque Bolt travaille alors sur sa propre copie du code (techniquement, un git worktree, avec une branche nommée d'après un identifiant court et le nom du morceau, par exemple bolt-7c31e9a0_salles). Chaque Bolt modifie ainsi ses fichiers à l'abri de l'autre. Un Bolt ne rejoint le code commun que si ses tests passent, et les Bolts le rejoignent un par un. Le Bolt des réservations, lui, attend que celui des salles soit intégré.

L'exemple, Bolt par Bolt

Voici comment l'équipe de l'application de réservation pourrait enchaîner ses six Bolts sur trois séances. Le découpage et les durées sont illustratifs.

Séance 1, matin. Bolt 1 : le squelette. Une seule salle, codée en dur. Un formulaire date et heure, un enregistrement en base, un test qui relit la réservation. L'agent lance pytest, qui passe. L'équipe approuve, choisit « continuer automatiquement » et l'exécution en essaim.

Séance 1, après-midi. Bolts 2 et 3, en parallèle.

• Bolt 2 (Unit salles). L'agent remplace la salle codée en dur par une vraie gestion des salles : nom, capacité, étage. Il demande si une salle peut être fermée pour travaux ; l'équipe répond oui, et l'agent ajoute un statut « indisponible ».
• Bolt 3 (Unit notifications). L'agent écrit l'e-mail de confirmation, déclenché à chaque réservation créée. Ses tests utilisent un faux serveur de messagerie. Ce Bolt touche d'autres fichiers que le Bolt 2, d'où le parallèle.

Le Bolt 2 finit le premier et rejoint le code commun. Le Bolt 3 relance alors ses tests sur le code à jour, puis le rejoint à son tour.

Séance 2. Bolt 4 (Unit réservations) : réserver une vraie salle. C'est le Bolt « créer une réservation » décrit plus haut. Il démarre seulement maintenant, parce qu'il a besoin des salles du Bolt 2. L'agent ajoute le choix de la salle, la règle anti-doublon et le contrôle de capacité. Un test échoue : l'agent a traité 10 h-11 h et 11 h-12 h comme deux créneaux qui se chevauchent. Il rend la main. L'équipe tranche (une réservation qui commence à l'heure où une autre finit est acceptée), l'agent corrige, les tests passent.

Séance 2, suite. Bolt 5 : l'annulation. Annuler une réservation libère le créneau et envoie un e-mail d'annulation. Ce Bolt touche les réservations et les notifications : il attend donc la fin des Bolts 3 et 4.

Séance 3. Bolt 6 : les réservations récurrentes. L'agent avait posé la question dès le premier plan ; l'équipe l'avait repoussée. Elle y revient maintenant, sur une base qui fonctionne : tous les mardis à 9 h, pendant dix semaines, avec un contrôle de doublon pour chaque occurrence.

Une fois les six Bolts intégrés, l'agent lance la compilation, les tests et la chaîne d'intégration continue sur l'ensemble. La phase Construction se termine là.

Bolt	Unit	Démarre après	Mode
1 Squelette	Réservations	Approbation du plan	Série, validé par l'équipe
2 Salles	Salles	Bolt 1	Parallèle avec le 3
3 Confirmation par e-mail	Notifications	Bolt 1	Parallèle avec le 2
4 Réserver une vraie salle	Réservations	Bolt 2	Série
5 Annulation	Réservations, notifications	Bolts 3 et 4	Série
6 Récurrence	Réservations	Bolt 5	Série

Sprint et Bolt, côte à côte

	Sprint (Scrum)	Bolt (AI-DLC)
Durée	Deux semaines	Quelques heures à quelques jours
Qui produit le code	Les développeurs	L'agent
Qui décide	L'équipe, en planning puis en revue	L'équipe, avant (plan) et après (résultat) chaque Bolt
Preuve de fin	Démo de fin de sprint	Tests qui passent, validation de l'équipe
Travail en parallèle	Chaque développeur sur ses tickets	Plusieurs Bolts, chacun sur sa copie du code

Les limites

Les gains publiés (68 à 87 % d'effort en moins chez ConnectiveRx) viennent d'engagements accompagnés et co-signés par AWS¹. Chaque Bolt consomme beaucoup de tokens, donc le coût se suit Bolt par Bolt. La cadence use les équipes : Julien Lépine, directeur de la technologie d'AWS France, cite un client qui a ramené son rythme sous trois Bolts par jour pour épargner à ses développeurs la surcharge cognitive⁶. Enfin, la documentation d'AWS précise qui approuve un plan et reste muette sur qui signe la mise en production.

Une équipe peut reprendre ces règles hors d'AI-DLC : faire tourner une version de bout en bout avant de construire le reste, et n'accorder d'autonomie à l'agent qu'après cette preuve.

Sources

1. Praveen Allam, David Caicedo, Rizwan Sarkhot, Sojung Lee, « How ConnectiveRx Accelerated Innovation with AI-DLC », AWS Public Sector Blog, 20 septembre 2026. aws.amazon.com
2. Raja SP, « AI-Driven Development Life Cycle: Reimagining Software Engineering », AWS DevOps Blog, 31 juillet 2025. aws.amazon.com
3. Dépôt awslabs/aidlc-workflows, GitHub, consulté en septembre 2026. github.com
4. AI-DLC User Guide, « Your First Workflow ». awslabs.github.io
5. Takeshi Shimada, « AIで紐解くAWS AI-DLC v2：並列実行 » (exécution parallèle, version 2.5.37), Qiita, 30 juin 2026. qiita.com
6. Bruno (hôte) et Julien Lépine (CTO AWS France), « AWS Summit : rester aux commandes des agents de code », podcast If This Then Dev #351, 8 avril 2026. ifttd.io