SDLC AI-native: sept pratiques pour une livraison fiable

Un agent de code peut terminer sa tâche alors que la modification attend encore sa revue ou son déploiement. Pour un CTO, le gain réel dépend de la rapidité avec laquelle l'ensemble de la modification atteint les utilisateurs, à un niveau de qualité et de coût acceptable.

Dans un cycle de développement logiciel (SDLC) AI-native, le travail de l'agent est intégré au processus de delivery de l'équipe, avec des tâches, des permissions et des critères d'acceptation définis. Les équipes donnent la direction et restent responsables de ce qui arrive en production. Ces recommandations s'appuient sur l'expérience terrain des équipes d'ingénierie d'Artefact.

1. Cartographiez le flux de delivery et identifiez le goulot d'étranglement

Prenez plusieurs modifications récentes et retracez leur parcours: cadrage, design, implémentation, tests, revue et déploiement. Séparez le temps passé à produire du temps passé à attendre ou à corriger. Cela permet de voir si le retard principal vient d'exigences floues, d'une suite de tests lente ou de la file d'attente de review.

Choisissez votre première expérimentation pour traiter ce retard précis. Si la revue de code est le goulot d'étranglement, générer plus de code risque d'aggraver la situation; préparer des preuves de tests ou réduire la taille des modifications sera bien plus utile. Mesurez l'impact jusqu'à la production pour vérifier si vous avez éliminé la contrainte ou simplement déplacée.

2. Rendez la demande testable et fournissez le contexte

Décrivez le comportement attendu, ce qui doit rester inchangé et les tests que le résultat doit valider.

Par exemple, «ajouter un export client» laisse trop de décisions ouvertes. Le brief doit préciser qui peut exporter quels enregistrements et champs, quelles limites s'appliquent et comment gérer les erreurs. Utilisez ces règles pour définir les critères d'acceptation.

Donnez à l'agent les conventions du repository, les interfaces pertinentes et les instructions pour lancer les tests. Maintenez ce contexte à jour, avec un responsable désigné. Quand une information essentielle manque, l'agent doit s'arrêter et poser une question ciblée plutôt que de choisir une interprétation plausible.

3. Définissez le périmètre d'action des agents et la validation des résultats

Donnez aux agents l'autonomie nécessaire pour implémenter les changements et exécuter les tests dans un périmètre convenu. Désignez un responsable pour la validation finale, avec des règles claires sur le moment où l'agent doit s'arrêter ou escalader.

Adaptez le niveau de revue aux conséquences d'une erreur. Une mise à jour de documentation et une modification de droits d'accès n'exigent pas les mêmes contrôles; formalisez les changements qui requièrent une validation humaine explicite.

Les tests automatisés peuvent passer à côté d'une mauvaise interprétation du besoin. Si un agent écrit à la fois le code et les tests, les deux peuvent reproduire la même erreur. Les reviewers doivent vérifier le comportement attendu et l'impact sur le reste du système, y compris les cas d'erreur que les tests de l'agent ont pu ignorer.

4. Contrôlez les accès et conservez un historique des actions

Exécutez le travail des agents dans un environnement isolé avec des permissions dédiées à la tâche. Restreignez les accès aux données et les identifiants, et utilisez le processus d'autorisation standard pour tout accès à la production. Un sandbox seul n'empêche pas un agent d'utiliser les accès qu'on lui a confiés.

Si un ticket ou un événement déclenche une session, définissez le travail qu'il autorise, ce que l'agent peut modifier et le moment où il doit s'arrêter.

Conservez un historique partagé des actions, des changements de code, des résultats de tests et des erreurs, accessible uniquement à l'équipe concernée, sans secrets ni données sensibles. Un autre ingénieur doit pouvoir comprendre le travail et prendre le relais sans dépendre de l'ordinateur de l'opérateur initial.

5. Évaluez les workflows complets sur des tâches représentatives

Construisez un jeu d'évaluation à partir de vos propres repositories, en intégrant les contraintes qui posent habituellement problème. Incluez des cas où la bonne réponse consiste à demander des clarifications ou à s'arrêter face à une limite de permissions.

Comparez des configurations complètes: modèle, instructions, contexte, outils et tests. Gardez des tâches et des critères d'acceptation fixes, puis mesurez les succès en parallèle des corrections humaines, du temps écoulé et du coût total. Répétez les cas critiques pour vérifier la régularité des résultats.

Utilisez des benchmarks publics pour présélectionner des solutions, puis décidez des déploiements sur la base des résultats obtenus dans votre environnement. Relancez les évaluations dès qu'un modèle ou un composant clé de la configuration change.

6. Mesurez le temps, la qualité, la valeur et les coûts

Distinguez bien deux métriques de temps:

• Le temps request-to-production commence avec un besoin validé et se termine quand la modification est exploitable en production. Il inclut le cadrage, l'attente et les corrections.

• Le change lead time de DORA s'étend du commit dans le gestionnaire de versions jusqu'au déploiement en production. Il couvre une portion plus ciblée du cycle.

Associez la vitesse à la qualité et aux preuves de la valeur créée. Pour une nouvelle fonctionnalité, mesurez son adoption; pour un correctif de fiabilité, suivez la réduction des incidents récurrents. Suivez également les échecs de déploiement et les anomalies détectées après la mise en production.

Pour le coût par changement validé, intégrez la consommation des modèles, l'infrastructure d'exécution ainsi que la revue et les corrections humaines. N'oubliez pas le coût des tentatives infructueuses. Définissez les critères d'acceptation à l'avance et comparez des tâches de complexité et de périmètre comparables.

7. Lancez un pilote sur une équipe avant de déployer à l'échelle

Commencez avec une seule équipe et une tâche répétable à faible impact en cas d'erreur. Avant le pilote, alignez-vous sur le périmètre, la baseline de performance et les résultats requis pour étendre l'usage. Fixez des critères clairs pour interrompre ou restreindre le test si nécessaire.

Servez-vous des cas réels du pilote pour former les équipes. Les Product Owners doivent s'entraîner à rédiger des critères d'acceptation précis; les ingénieurs doivent apprendre à détecter un résultat séduisant mais incorrect. Assurez-vous que l'équipe sait analyser un échec et exécuter la procédure de reprise, même si l'agent ou son fournisseur est indisponible.

Passez à l'échelle quand les résultats atteignent les objectifs fixés et que l'équipe maîtrise le workflow sans dépendre d'un expert unique.

Lors de votre prochain point de planification, prenez un changement qui a pris du retard et analysez où il a bloqué. Si vous souhaitez de l'aide pour transformer ce diagnostic en un premier pilote, contactez Agilytic.