9. Des tests unitaires à la fonctionnalité livrée
9.1 La boucle extérieure et les boucles intérieures
Le TDD à deux boucles relie le résultat métier et les composants. Un test d’acceptation extérieur définit une fonctionnalité attendue. Pour le faire passer, l’équipe réalise plusieurs classes ou objets, chacun au moyen de cycles unitaires courts. Les composants sont intégrés jusqu’à ce que le comportement de la fonctionnalité entière soit satisfait.
La boucle extérieure évite de perdre le but final en améliorant des morceaux isolés. Les boucles intérieures apportent des diagnostics précis et une rétroaction rapide pendant la construction. Un test d’acceptation ne remplace donc pas tous les tests unitaires, et une collection de tests unitaires verts ne prouve pas à elle seule que la fonctionnalité est bien intégrée.
9.2 Intégrer les petits pas et contrôler l’activation
L’intégration fréquente réduit le temps pendant lequel un changement reste séparé du logiciel réel. Le conférencier évoque la possibilité d’intégrer une composante qui n’est pas encore branchée dans les parcours utilisés. Pour un travail plus long, des feature switches, ou interrupteurs de fonctionnalités, permettent de contrôler l’activation d’une partie expérimentale.
On peut ainsi intégrer et tester progressivement sans exposer automatiquement la nouveauté à tous les clients. Le mécanisme vise à obtenir de la rétroaction tôt, plutôt qu’à découvrir les interactions à la fin d’un grand lot. Il reste nécessaire de vérifier le code intégré, les parcours actifs et les comportements disponibles.
9.3 CI et CD sont liés, mais intégrer n’est pas installer partout
La CI, intégration continue, réduit le délai entre une modification et sa validation dans la solution intégrée. La CD, livraison continue dans l’échange de la séance, prolonge cette capacité vers la livraison. Une organisation peut intégrer continuellement sans envoyer chaque changement immédiatement chez tous les clients. Pouvoir livrer en continu suppose cependant de pouvoir intégrer et valider en continu.
L’intervenant note que ces termes sont parfois rapprochés dans l’usage, mais sa réponse distingue bien leur portée : intégrer une modification et la livrer en production ne désignent pas la même décision. Il faut conserver cette distinction pour comprendre son exemple industriel.
Algosys peut livrer fréquemment à l’interne tout en regroupant les installations externes selon les besoins. Une usine en activité 24 h/24 ne reçoit pas forcément chaque modification à la minute. La capacité technique et la décision opérationnelle de déployer sont donc deux éléments distincts.
9.4 Les contraintes industrielles influencent le déploiement
Les installations locales, l’isolement géographique, la connectivité, la propriété intellectuelle et la sécurité des opérations peuvent influencer les choix. Certains clients veulent garder le produit sur leurs serveurs et isoler leur réseau. Le conférencier cite Starlink comme exemple d’amélioration de la connectivité, sans dire qu’elle a supprimé toutes ces contraintes.
À une question sur le cloud, il répond que certains clients n’en veulent pas. Des logiciels industriels peuvent interagir avec des équipements dont une mauvaise commande aurait des conséquences physiques. Les exemples cités portent sur des produits dangereux et les barrages de résidus miniers; ils expliquent la prudence des clients face à l’exposition au réseau. Ils ne constituent pas une comparaison générale démontrée de la sécurité de tous les modes d’hébergement.
L’offre évolue également vers des services hébergés. L’expérience du groupe ION dans le secteur bancaire est évoquée comme un élément de crédibilité dans les discussions de sécurité. Le contexte et le niveau d’acceptation de chaque client restent déterminants.
9.5 La maintenance commence après la première livraison
Un projet scolaire peut être remis puis laissé derrière. Le produit professionnel reste souvent pendant des années. Une nouvelle demande peut, par exemple, ajouter un titre à la salutation. La personne qui modifie une vieille zone ne possède plus forcément tous les détails en mémoire.
Les tests conservés permettent de reconnaître une rupture involontaire des anciennes attentes pendant l’ajout du besoin nouveau. Cette utilité de maintenance explique une grande partie du retour sur investissement : ils servent lorsque le code revient au travail, pas seulement le jour où il a été écrit.