Les tests SIT, pour system integration testing ou tests d’intégration système, vérifient que votre logiciel fonctionne correctement avec les autres systèmes dont il dépend, comme un prestataire de paiement, une banque ou la base de données d’un partenaire. Dans l’ordre habituel, ce niveau intervient après que votre propre produit a réussi les tests système et avant que les utilisateurs métier essaient l’ensemble dans les tests d’acceptation.
Faire l’impasse sur les tests SIT est risqué lorsque différentes entreprises développent et exploitent les briques dont dépend votre produit. Chaque équipe peut réussir ses propres contrôles alors que le lien entre deux systèmes échoue toujours. Cette défaillance apparaît souvent d’abord sous les yeux des clients. Pour l’éviter, décidez tôt qui teste ces connexions, dans quel environnement et avec les données de qui.
Comme ces vérifications supposent que plusieurs responsables de systèmes travaillent ensemble, la tâche revient souvent à une équipe d’assurance qualité dédiée capable de coordonner les tests avec chaque fournisseur concerné. Dans cet article, nos ingénieurs QA expliquent ce que couvrent les tests d’intégration système, en quoi cette méthode diffère des tests d’intégration et des tests d’acceptation utilisateur (UAT), et dans quels projets cette étape supplémentaire est rentable.
Que vérifient réellement les tests SIT ?
Les tests SIT examinent la façon dont votre produit se connecte aux services externes. L’International Software Testing Qualifications Board (ISTQB), l’organisme international qui certifie les testeurs de logiciels, définit les tests d’intégration système comme la vérification « des interfaces du système testé avec d’autres systèmes et services externes ». En termes simples, une interface est le point où deux logiciels se transmettent des données.
Prenez une boutique en ligne qui transmet chaque commande à un prestataire de paiement, à la base de données d’un entrepôt et à un service d’e-mail. Chacun de ces services peut parfaitement fonctionner seul. Les tests SIT vérifient si la commande arrive toujours complète et correcte après chaque transmission.
En pratique, les testeurs recherchent quatre types de problèmes :
- Données incompatibles : un service envoie une date, un prix ou une adresse dans un format que l’autre côté interprète différemment.
- Transmissions interrompues : un message se perd, arrive en double ou arrive trop tard pour servir.
- Pannes non gérées : lorsque le service d’un partenaire est hors ligne, votre produit se fige sans expliquer à l’utilisateur ce qui s’est passé.
- Accès refusé : le jeton de sécurité de votre produit, une clé numérique temporaire qui prouve qui demande les données, fonctionne dans votre propre système mais est refusé par le service à l’autre bout.
Beaucoup de ces bugs remontent à quelques schémas récurrents de défaillance d’intégration, comme des notifications automatiques qui n’arrivent jamais ou des réponses qui signalent un succès tout en masquant une erreur.
SIT, tests d’intégration et UAT : la place de chacun
On confond souvent les SIT, les tests d’intégration et l’UAT, car les trois concernent des logiciels qui fonctionnent ensemble. La différence tient à l’échelle et à la question à laquelle répond chaque niveau. Le programme actuel de l’ISTQB divise même les tests d’intégration en deux : les tests d’intégration de composants, pour les briques d’un même produit, et les tests d’intégration système, pour les connexions entre produits.
Les tests d’intégration consistent généralement à vérifier deux briques développées par vos propres développeurs, comme un formulaire d’inscription et la base de données qui enregistre les nouveaux comptes. Les SIT élargissent le périmètre aux systèmes qui appartiennent à d’autres équipes ou fournisseurs, par exemple un prestataire de paiement ou le service de cartes d’une banque. Les tests d’acceptation utilisateur confient le produit fini et connecté aux utilisateurs métier, qui peuvent par exemple confirmer qu’une commande client se déroule comme prévu.
Le tableau ci-dessous compare les SIT et l’UAT, ainsi que les deux niveaux qui les précèdent :
Question clé
Les briques de notre produit fonctionnent-elles ensemble ?
Notre produit complet fonctionne-t-il comme prévu ?
Notre produit fonctionne-t-il avec les systèmes qui l’entourent ?
Le produit connecté répond-il aux besoins métier ?
Périmètre
Les briques du code d’un produit
Un produit complet
Votre produit plus les systèmes et services externes
L’ensemble dans des scénarios métier réels
Testeurs habituels
Développeurs
Testeurs indépendants
Testeurs indépendants, avec chaque responsable de système
Utilisateurs métier ou personnel du client
Exemple d’application bancaire
Le formulaire de prêt enregistre les données dans la base de l’application
Chaque fonction de l’application est vérifiée par rapport aux exigences
L’application échange des données avec le processeur de cartes et le bureau de crédit
Le personnel de l’agence confirme que le processus de prêt correspond à sa façon de travailler
Quand votre projet a-t-il besoin de tests SIT ?
Vous avez besoin de tests SIT lorsque votre produit dépend de systèmes que vous ne contrôlez pas. Le risque est le plus élevé dans les grandes entreprises, où votre application échange des données avec des outils appartenant à d’autres équipes, comme une base de données clients ou un progiciel de gestion intégré (ERP), le logiciel qui gère la finance, les stocks et la paie. Les parcours de paiement et d’identité demandent le même soin, car l’argent ou les données personnelles transitent par un prestataire de paiement, une banque ou un service de vérification.
Les logiciels anciens augmentent eux aussi l’enjeu, car une nouvelle application doit souvent fonctionner avec un système que personne ne veut modifier. Le cas le plus récent est celui d’un assistant d’IA capable de mettre à jour votre agenda, vos fiches clients ou vos tickets d’assistance, car il se connecte séparément à chacune de ces applications, et chacun de ces liens peut échouer.
Dans l’UE, les banques, les assureurs et les autres entités financières ont en plus une raison légale de tester ces connexions. En vertu du règlement sur la résilience opérationnelle numérique (DORA), ces entreprises doivent vérifier régulièrement la résistance de leurs systèmes sous pression, et les prestataires technologiques externes peuvent devoir y participer.
À l’inverse, un produit simple, développé par une seule équipe et qui s’appuie sur peu de services tiers, demande beaucoup moins de ce travail. Dans ce cas, de bons tests d’intégration et tests système couvrent généralement le risque. Les tests de bout en bout, qui suivent le parcours réel d’un utilisateur dans l’application du début à la fin, rattrapent ensuite ce que ces deux niveaux ont manqué.
La place des tests SIT dans votre stratégie de test
Les SIT interviennent généralement vers la fin de la séquence de tests. L’ISTQB décrit cinq niveaux de test, et la plupart des projets les exécutent à peu près dans cet ordre :
- Tests de composants : les développeurs vérifient chaque petit morceau de code isolément.
- Tests d’intégration de composants : la même équipe confirme que ces morceaux fonctionnent ensemble.
- Tests système : des testeurs indépendants comparent le produit complet à ses exigences.
- Tests d’intégration système : l’équipe de test vérifie les connexions du produit avec les systèmes externes.
- Tests d’acceptation : les utilisateurs métier confirment que le produit répond à leurs besoins.
Dans les projets réels, les niveaux se chevauchent. Une équipe peut commencer à vérifier une connexion terminée pendant que d’autres fonctionnalités sont encore en tests système, ce qui fait apparaître plus tôt les problèmes côté partenaires. L’ordre compte malgré tout. Si votre propre produit présente encore des bugs ouverts, l’échec d’une vérification de connexion peut venir de votre code ou du système du partenaire, et personne ne peut dire lequel. La même confusion peut aussi naître de l’autre côté. Pour Granola, un bloc-notes à base d’IA, une connexion Google peu fiable faisait échouer les tests automatisés alors même que l’application fonctionnait. Nous avons donc créé un outil de connexion interne et sécurisé qui a écarté ces faux échecs des résultats.
Critères d’entrée et de sortie : quand les SIT peuvent commencer et quand ils sont terminés
Les critères d’entrée et de sortie définissent ce qui doit être en place avant le début des tests SIT et ce qui permet de les considérer comme terminés. S’accorder sur ces deux listes dès le départ évite les désaccords entre fournisseurs par la suite.
Les tests peuvent commencer lorsque :
- Les parties de votre produit concernées par chaque connexion ont réussi les tests système, sans bug critique ouvert.
- Chaque partenaire a fourni une sandbox, une copie de test qui se comporte comme le service réel.
- Des enregistrements d’exemple correspondants existent de tous les côtés, par exemple le même client test dans votre application et à la banque.
- Chaque responsable de système a désigné un interlocuteur capable d’analyser les défaillances de son côté.
Le travail est terminé lorsque :
- Chaque connexion prévue a été testée, y compris ce qui se passe lorsqu’un partenaire est hors ligne.
- Aucun bug critique ou de priorité élevée ne reste ouvert.
- Le responsable de chaque système a validé les résultats pour sa partie.
Quelles sont les quatre approches des tests SIT ?
Tout projet de tests SIT doit décider dans quel ordre les systèmes sont intégrés. Cette séquence influe sur la rapidité avec laquelle les problèmes sont découverts et sur la facilité à remonter à l’origine de chaque défaillance. Quatre approches sont les plus utilisées :
- Big bang : tout est connecté en une fois et testé ensemble. L’approche convient aux petites configurations, mais chaque système ajouté rend la cause d’une défaillance plus difficile à trouver.
- Descendante (top-down) : l’équipe commence par l’application avec laquelle vos utilisateurs interagissent et ajoute un par un les services internes et partenaires situés derrière. Tant que la brique suivante n’est pas prête, les testeurs utilisent des stubs, des substituts simples qui renvoient des réponses prédéfinies.
- Ascendante (bottom-up) : le travail commence par les systèmes back-end centraux, comme le traitement des paiements et votre base de données principale, puis remonte vers ce que les gens voient. Tant que les applications côté client ne sont pas connectées, les testeurs utilisent des drivers, de petits programmes qui envoient les mêmes requêtes que celles que déclencheront plus tard les actions des utilisateurs.
- Sandwich : les équipes testent à la fois par le haut et par le bas et se rejoignent au milieu, ce qui convient aux grands projets où de nombreux groupes travaillent en parallèle.
Pour un projet impliquant plusieurs fournisseurs, les approches descendante, ascendante ou sandwich sont généralement payantes, car chaque nouvelle connexion est vérifiée séparément et chaque défaillance a donc une origine évidente. La plupart des systèmes échangent des données au moyen d’interfaces de programmation d’applications (API). Une API est un ensemble fixe de requêtes qu’un programme peut envoyer à un autre, un peu comme la carte des commandes qu’accepte une cuisine. Une fois les connexions stables, les tests automatisés d’API peuvent rejouer les scénarios clés après chaque version.
Comment QAwerk mène les SIT entre équipes et fournisseurs
QAwerk rejoint les tests SIT en formant une seule équipe avec vos développeurs et vos fournisseurs. La première étape est une cartographie de toutes les connexions, qui indique le responsable de chaque système et les données qui transitent par chaque lien. Nous convenons ensuite avec chaque fournisseur de l’accès à la sandbox, des comptes de test et des données d’exemple utilisables. Nos ingénieurs couvrent alors le flux normal ainsi que les défaillances, comme un partenaire qui répond lentement, envoie des données erronées ou passe hors ligne. Chaque bug part directement vers l’équipe capable de le corriger, avec les éléments nécessaires pour reproduire le problème.
Les détails varient selon les systèmes concernés. Par exemple, chez Thirdfort, une application réglementée de vérification d’identité, nous avons testé la vérification des pièces d’identité reposant sur les kits de développement Onfido et ReadID, ainsi que la liaison de relevés bancaires qui montre l’origine des fonds d’un client. Onfido figurait aussi dans ChitChat, une application de messagerie permettant d’envoyer de l’argent à des amis, mais le travail y portait sur la façon dont l’application échangeait des données avec ce service et avec Primer, son prestataire de paiement. Arctype, en revanche, demandait un autre type de travail d’intégration. Pour cette application, qui permet aux développeurs d’interroger et de gérer des bases de données, nous avons testé les connexions à cinq systèmes de bases de données : MySQL, PostgreSQL, SQLite, Yugabyte et PlanetScale.
Nous pouvons intervenir avant votre première intégration avec un partenaire ou en plein déploiement. Les ingénieurs de QAwerk évaluent l’état du projet, définissent le périmètre et livrent des résultats exploitables tout de suite. Prêt à lancer vos tests d’intégration système ? Contactez-nous dès aujourd’hui.
Questions fréquentes
Qu’est-ce que les tests SIT ?
Les tests SIT (tests d’intégration système) constituent l’étape qui vérifie un produit avec les services externes qui y sont connectés, comme une passerelle de paiement, un partenaire logistique ou l’outil comptable d’une entreprise. Leur but est de repérer les défaillances qui n’apparaissent que lorsque des systèmes développés séparément échangent des informations, par exemple une commande que le logiciel de l’entrepôt rejette ou un remboursement qui n’atteint jamais le client.
Les SIT ont-ils lieu avant l’UAT ?
Oui, les tests d’intégration système (SIT) se terminent normalement avant les tests d’acceptation utilisateur (UAT), le dernier contrôle, où les utilisateurs métier décident si le logiciel convient à leur travail quotidien. Cet ordre préserve leur temps. Si des achats ou des paiements échouent encore entre des systèmes connectés, les testeurs d’acceptation finissent par consigner des bugs techniques et ne peuvent pas juger le processus lui-même. Un bref chevauchement est courant, mais les bugs d’intégration critiques doivent être corrigés d’abord.
Quelle est la différence entre les SIT et les tests système ?
Les tests système regardent vers l’intérieur et vérifient qu’un produit complet répond à ses exigences, souvent avec des services partenaires simulés. Les SIT regardent au contraire vers l’extérieur et remplacent ces simulations par de vrais systèmes partenaires ou des sandboxes réalistes. Par exemple, le paiement d’une boutique en ligne peut réussir les tests système avec un faux service de paiement puis échouer aux SIT parce que le vrai prestataire attend des montants en centimes alors que la boutique les envoie en euros.
Qui réalise les tests d’intégration système ?
Les tests SIT sont généralement pilotés par des testeurs indépendants, soit l’équipe QA interne d’une entreprise, soit un prestataire QA externe, car le travail couvre des systèmes qui n’appartiennent à aucun développeur en particulier. Chaque partenaire ou équipe interne désigne un interlocuteur qui accorde l’accès de test et analyse les défaillances de son côté. Les développeurs corrigent les bugs trouvés dans leur code, et les utilisateurs métier interviennent plus tard pour les tests d’acceptation.
Peut-on automatiser les SIT ?
Les tests SIT peuvent être partiellement automatisés. Les vérifications stables et reproductibles, comme l’envoi d’un paiement d’exemple vers la sandbox d’un prestataire et le contrôle de la réponse, peuvent s’exécuter automatiquement après chaque version. Les testeurs manuels restent indispensables pour les nouvelles connexions partenaires, les scénarios de défaillance inhabituels et les environnements de test qui se comportent différemment du service réel. Une répartition courante consiste à automatiser les flux principaux éprouvés et à explorer manuellement tout ce qui est nouveau.
Découvrez comment nous avons livré des flux d’intégration stables, de vérification d’identité et de Source de Fonds pour une fintech britannique construite sur de profondes intégrations tierces.
