Plus vite, sans bâcler

Plus vite : ce que ça veut dire

La plupart des projets logiciels ne sont pas lents parce que les gens tapent lentement. Ils sont lents à cause de l’attente : une décision, une revue, un bogue qui aurait dû être repéré le mois dernier et qu’il faut trouver et corriger. Ils sont lents parce que des ingénieurs d’expérience passent des journées sur du code répétitif qu’un junior pourrait écrire, pendant que les questions difficiles les attendent.

Alors quand nous disons plus vite, nous voulons dire moins d’attente et moins de reprises. Pas moins de tests, moins de revues ni une documentation plus mince. Ce sont justement ces choses qui ralentissent un projet plus tard, habituellement après le lancement, quand corriger un problème dérange le plus.

Vous ne trouverez pas ici la promesse qu’un projet prend une fraction du temps habituel. Chaque projet est différent, et un tel chiffre ne vous dirait rien sur le vôtre. Ce que nous pouvons décrire, c’est comment le travail est organisé et comment il est vérifié, pour que vous en jugiez vous-même; c’est dans les étapes de votre propre échéancier que vous le verrez.

Les agents bâtissent, les ingénieurs dirigent

Chaque projet comporte un grand volume de travail nécessaire, mais pas nouveau : l’ossature du projet, les écrans et formulaires standards, les interfaces entre les parties, le code qui lit et écrit les enregistrements, les connexions à des services bien documentés, et les suites de tests qui couvrent tout cela. Il doit être bien fait, mais il ne demande pas le jugement d’un ingénieur d’expérience à chaque ligne.

Dans notre façon de travailler avec des agents, ce sont des agents d’IA qui bâtissent ces fondations. Ils travaillent selon une spécification écrite par nos ingénieurs, dans la structure fixée par nos architectes, et chaque changement qu’ils font est révisé par un ingénieur avant d’être intégré. Les agents ne décident pas quoi construire, de la forme du système ni de l’acceptation d’un changement. Ce sont des personnes qui en décident.

• L’ossature : structure du projet, configuration, chaînes de compilation et de déploiement, environnements.
• Les interfaces : les contrats typés entre le frontal, le serveur et les services externes, écrits en premier pour que chaque partie s’y conforme.
• Les fonctions standards : formulaires, listes, pages de détail, réglages, enregistrements créés, lus, modifiés et supprimés.
• Les intégrations avec des services bien documentés, derrière des interfaces définies par nos ingénieurs.
• Les suites de tests : tests unitaires et d’intégration pour tout ce qui précède, écrits en même temps que le code plutôt qu’après.
• Les premières versions de la documentation technique, que les ingénieurs corrigent et complètent ensuite.

Tout commence par la spécification

Des agents dirigés ne valent que leurs directives. Avant tout travail de fondation, nos ingénieurs écrivent ce que chaque partie doit faire : les données qu’elle contient, l’interface qu’elle expose, les règles qu’elle applique, les erreurs qu’elle renvoie et les tests qui le prouvent. Cette spécification est le même document dont une équipe humaine aurait besoin, et elle fait partie du transfert.

L’écrire d’abord a un avantage qui dépasse les agents. Les ambiguïtés de vos exigences ressortent dans les premières semaines, sous forme de questions que nous vous posons, plutôt que des mois plus tard sous forme de fonctions qui marchent, mais font la mauvaise chose.

Ce que gardent nos ingénieurs d’expérience

Confier les fondations à des agents dirigés, ce n’est pas faire moins d’ingénierie. C’est placer les personnes les plus expérimentées là où leur jugement compte le plus, pendant une plus grande partie du projet.

Pour vous, le résultat est que les personnes les plus expérimentées ne passent pas leur semaine sur la validation de formulaires. Elles réfléchissent à la protection de vos données, à ce qui arrive quand deux personnes modifient le même enregistrement, au comportement du système quand un service externe est en panne, et à savoir si le produit fait ce dont vos utilisateurs ont besoin.

Les tests d’abord, et des tests pour les tests

Du code produit rapidement doit être vérifié à fond, et une suite de tests n’est utile que si elle attrape vraiment les erreurs. Une suite peut exécuter chaque ligne de code sans rien vérifier d’important. Alors nous testons nos tests.

Les tests de mutation servent à cela. Un outil introduit délibérément de petits bogues dans le code, un à la fois, et exécute les tests sur chaque version modifiée. Si les tests échouent, le bogue a été attrapé; s’ils réussissent, les tests ont une faille ^[1]. Nous appliquons les tests de mutation au code qui compte le plus : les permissions, l’argent, l’intégrité des données et tout ce qu’un organisme de réglementation ou un auditeur demanderait.

• Des tests unitaires pour la logique, des tests d’intégration pour les parties qui travaillent ensemble, et des tests de bout en bout pour les parcours de vos utilisateurs.
• Des tests qui roulent sur une vraie base de données, reconstruite à partir des migrations chaque fois, pas sur une version simplifiée.
• Des tests de mutation sur le code critique, chaque mutant survivant étant traité comme un défaut des tests.
• Du fuzzing et des tests de propriétés là où les données viennent de l’extérieur : téléversements, importations, API publiques et contrats intelligents.

Des revues à chaque niveau

Le Secure Software Development Framework du NIST souligne que les pratiques de développement sécuritaire doivent habituellement être ajoutées délibérément au processus d’une équipe, pour réduire les vulnérabilités des logiciels publiés et s’attaquer à leurs causes profondes ^[2]. Les revues sont notre principal moyen d’y arriver, à trois niveaux.

1. 01

   Chaque changement

   Un ingénieur révise chaque changement avant son intégration, qu’il ait été écrit par une personne ou par un agent. Il vérifie qu’il fait ce que dit la spécification, qu’il est testé et qu’il n’affaiblit rien autour.

2. 02

   Chaque étape

   Avant de vous parvenir, une étape est testée comme un tout dans un environnement de préproduction : les fonctions, les cas limites et les parcours de bout en bout.

3. 03

   Chaque phase

   À la fin de chaque phase, nous faisons une série complète de revues adverses : des personnes qui tentent délibérément de briser la sécurité, les permissions, le traitement des données et les hypothèses. Les constats sont corrigés avant le début de la phase suivante.

Pour les applications web, nous vérifions la sécurité selon une norme publiée. L’Application Security Verification Standard de l’OWASP est une liste d’exigences pour tester les contrôles de sécurité d’une application web ^[3], et elle donne aux deux parties un langage commun sur ce qui a été vérifié ou non.

Une vérification que vous pouvez voir

Vous ne devriez rien avoir à croire sur parole. Dans nos projets, les preuves font partie de la livraison.

• Chaque changement exécute automatiquement toute la suite de tests avant de pouvoir être intégré, et vous pouvez voir les résultats.
• Chaque étape est présentée dans un environnement de préproduction que vous pouvez utiliser vous-même avant de l’accepter.
• Les constats des revues et leur résolution sont consignés, pour qu’un auditeur ou votre propre équipe puisse les suivre.
• Le code, les tests et l’historique sont dans un dépôt à votre nom dès la première semaine.

Là où nous ralentissons exprès

Certains travaux ne devraient jamais être bousculés, et nous n’essayons pas. Une migration de données depuis votre ancien système est répétée sur une copie avant de toucher aux vraies données. Un contrat intelligent qui détiendra de la valeur est figé, révisé et, quand il le justifie, audité à l’externe avant son déploiement, parce qu’il ne peut pas être corrigé discrètement ensuite. Un modèle qui répond à vos clients est mesuré sur un jeu d’évaluation avant chaque changement. Les permissions et les paiements ont un deuxième réviseur.

Être rapides sur les fondations, c’est ce qui nous laisse la place d’être prudents ici. Cet échange est tout l’intérêt de notre façon de travailler.

Ce que cela veut dire pour vous

• Du logiciel qui fonctionne plus tôt. Les fondations arrivent vite : vous voyez de vrais écrans et de vraies données plus tôt, et vous pouvez corriger le tir pendant que c’est encore facile.
• Plus d’attention des personnes d’expérience sur ce qui compte. L’architecture, la sécurité et la logique centrale de votre projet reçoivent une plus grande part du temps de nos gens les plus expérimentés.
• Moins de surprises après le lancement. Des tests eux-mêmes testés et des revues de phase repèrent les problèmes pendant qu’ils sont encore faciles à corriger, sans grand effort ni dérangement.
• Une base de code qu’une autre équipe peut reprendre. Une structure cohérente, des interfaces typées et des tests complets facilitent le transfert.

Rien de tout cela ne change qui est responsable. Nos ingénieurs répondent de chaque ligne livrée, peu importe comment elle a d’abord été écrite.

Les questions à poser sur l’IA d’un studio

1. 01

   Qui révise le code écrit par l’IA?

   Chaque changement devrait être révisé par un ingénieur avant d’être intégré. Demandez comment c’est imposé.

2. 02

   Qu’est-ce qui n’est jamais délégué?

   La sécurité, les paiements, les modèles de données et tout ce qui est critique devraient rester entre les mains de personnes d’expérience. Demandez la liste.

3. 03

   Où vont mon code et mes données?

   Demandez quels outils voient votre code, à quelles conditions, et si quoi que ce soit est conservé ou sert à l’entraînement.

4. 04

   Comment savez-vous que les tests fonctionnent?

   La couverture seule n’est pas une réponse. Les tests de mutation, ou quelque chose d’équivalent, en sont une.

5. 05

   Qu’est-ce que je pourrai voir?

   Les résultats des tests, les registres de revue et un environnement de préproduction sont des attentes raisonnables.