Analyse des interfaces
L'analyse des interfaces (interface analysis, BABOK 10.24) recense les points où une solution échange de l'information avec ce qui l'entoure, et fixe les termes de chaque échange. Le BABOK y donne au mot interface une portée large: un écran utilisé par un employé, une autorité qui reçoit une déclaration obligatoire, un processus métier qui passe la main à un autre, un flux de données entre deux systèmes, une API et un appareil sont tous des interfaces au sens de la technique. Son produit est un contrat de frontière: ce qui traverse, dans quel sens, sous quel format, à quelle fréquence, en quel volume, sur quel déclencheur, selon quelles règles de validation, avec quel comportement en cas d'échec et sous la responsabilité de qui de chaque côté. Une interface qu'on n'a pas identifiée est une fonctionnalité qu'on n'a pas construite, et elle se découvre à l'intégration, au moment où elle coûte le plus cher.
Objectif
La technique sert trois décisions, et elles arrivent dans cet ordre. Elle assure d'abord la couverture fonctionnelle: le BABOK en fait sa première force, une analyse des interfaces menée tôt augmente la couverture des exigences, parce que chaque échange oublié est une fonctionnalité absente du périmètre et du chiffrage. Elle permet ensuite l'allocation: une fois la frontière spécifiée, on sait quel côté porte quelle règle. Valider un numéro AVS est le travail de quelqu'un, et la spécification est l'endroit où ce quelqu'un est désigné. Elle oriente enfin l'élicitation: la liste des interfaces nomme les contreparties, donc les parties prenantes, donc les personnes qu'il faut réunir pour la suite du travail d'exigences. C'est à ce titre que la technique appartient autant à l'élicitation qu'à l'analyse des exigences.
Le livrable est double. Le catalogue d'interfaces est l'inventaire: une ligne par interface, avec sa contrepartie, son sens, son type, son format, sa fréquence, son volume et son propriétaire. La spécification d'interface est le contrat: pour chaque interface qui le mérite, la définition champ par champ du message, les règles de validation, la transformation, les déclencheurs y compris les déclencheurs d'échec, le comportement en erreur, le niveau de service, la sécurité et la version en vigueur. L'ingénierie des systèmes appelle ce second document un Interface Control Document, et le manuel d'ingénierie système de la NASA en fixe la famille (document d'exigences d'interface, document de contrôle d'interface, document de description d'interface). La norme ISO/IEC/IEEE 29148:2018 porte les exigences d'interface externe à l'intérieur de la spécification des exigences système. Sur un projet conduit sous HERMES, la méthode de gestion de projet de la Confédération, cet inventaire est prescrit: les objets d'intégration et les interfaces forment l'une des neuf rubriques du concept d'intégration, à côté de l'aperçu du système, des environnements et des étapes d'intégration, des risques et de l'assurance de la qualité.
Usage
Quand l'utiliser
- Frontière de solution fraîchement tranchée: chaque franchissement du périmètre est une interface à spécifier et à chiffrer.
- Progiciel ou SaaS en cours de sélection: les interfaces au paysage applicatif existant portent l'essentiel du coût d'intégration.
- Remplacement d'un système hérité: ses interfaces sont l'inventaire de ce que le successeur doit encore satisfaire.
- Échange imposé par un standard: ELM, ISO 20022, eCH, le contrat vient de l'extérieur et le travail consiste à le lire.
- Chiffrage d'une intégration: volume et fréquence par interface transforment une liste en un montant.
- Planification de l'élicitation: la liste des interfaces nomme les contreparties à faire venir en séance.
- Passage de main entre deux unités ou deux entreprises: c'est là que la responsabilité se perd.
- Dossier de changement à étayer: l'usage réel et les incidents des interfaces actuelles sont des preuves chiffrées.
Quand ne pas l'utiliser
- Comportement interne d'un composant: la limite du BABOK, recourir à l'analyse des règles métier ou à un modèle de données.
- Périmètre encore ouvert: spécifier les franchissements d'une ligne non convenue produit un catalogue jetable, cadrer d'abord avec la modélisation du périmètre (BABOK 10.41).
- Ordonnancement des messages en question: le diagramme de séquence (BABOK 10.42) dit dans quel ordre, ce que la spécification ignore.
Les six types d'interface
Le BABOK énumère six types, et cette liste est le point que les praticiens manquent le plus souvent, parce qu'ils entendent interface et pensent API. Les interfaces utilisateur sont les écrans par lesquels des personnes de l'organisation interagissent directement avec la solution. Les personnes externes à la solution sont les parties prenantes, les régulateurs et les autorités qui reçoivent ou fournissent de l'information: en Suisse, une caisse de compensation AVS, une administration fiscale cantonale et un office statistique qui collecte un relevé obligatoire sont des interfaces à part entière, avec un format, une échéance et un mode de défaillance. Les processus métier forment une interface lorsqu'un processus passe l'information à un autre, y compris à l'intérieur de la même entreprise. Les interfaces de données entre systèmes sont les échanges classiques, lot nocturne, réplication, file de messages. Les interfaces de programmation applicative, les API, sont l'interface publiée d'un composant appelable. Les appareils sont les interfaces matérielles, lecteur de badge, terminal de paiement, capteur d'atelier.
Cette étendue ancre la technique dans la business analyse, et le BABOK en tire une force: son application large lui évite de sur-analyser le détail fin. Les deux types que personne ne catalogue sont l'autorité publique et le passage de main entre processus. L'architecte d'intégration ne les trouvera pas, parce qu'ils ne figurent dans aucune configuration technique.
HERMES traite les interfaces entre une organisation de projet temporaire et l'organisation permanente qui l'accueille (Stammorganisation): la méthode garantit la compatibilité de ces interfaces standardisées, le reporting par exemple. Elle nomme les trois rôles indispensables à leur fonctionnement: le mandant, le chef de projet et le représentant des utilisateurs. Ce qui traverse cette frontière est nommé: rapport sur l'état du projet, rapport de phase, rapport de release. Ce passage de main relève du type processus métier et se catalogue comme les autres, avec son émetteur, son destinataire, sa fréquence, son contenu et son échéance.
L'interface matérielle
Un appareil échange de la matière et de l'énergie autant que des messages, et sa spécification porte des rubriques qu'aucun échange de fichiers ne connaît. La forme vient en premier: la géométrie, l'encombrement, le connecteur, la fixation, le sens du montage, tout ce qui décide si les deux pièces s'assemblent. La tenue en service est l'exigence non fonctionnelle du monde physique: la plage de température, la résistance mécanique aux chocs et aux vibrations, la résistance chimique aux produits de nettoyage, l'étanchéité à la poussière et à l'eau. Le medium qualifie ce qui traverse physiquement la frontière: un gaz, un liquide, une pièce, sous quelle pression et à quel débit. L'énergie est une entrée à part entière: la tension, le courant, la puissance, la mise à la terre et la question de savoir lequel des deux côtés alimente l'autre.
La communication se déplie ensuite en trois étages qu'on a tendance à confondre. Le support et l'encodage: la paire torsadée, la boucle de courant 4-20 mA, le bus de terrain et la manière dont les bits sont portés par le signal, un codage NRZ, un codage Manchester. Le protocole: la trame, l'adressage, le contrôle d'erreur, la cadence des échanges, Modbus RTU, CAN, OPC UA. La sémantique: ce que la valeur veut dire. Un capteur de température dans une cuve de pasteurisation renvoie l'entier 3820 sur un registre Modbus, le protocole est respecté et rien n'est encore spécifié, parce que 3820 vaut 38,2 °C sous un facteur d'échelle de 0,01 et une lecture en degrés Celsius, mais tout autre chose sous une autre convention. Un protocole conforme et une sémantique supposée produisent une valeur juste qu'on interprète faux. La spécification est l'endroit où l'unité, le facteur d'échelle, la plage valide et la valeur convenue pour un capteur en défaut sont écrits.
Identifier les interfaces
La préparation consiste à rassembler ce qui existe déjà. Le BABOK nomme l'analyse documentaire, l'observation, les entretiens, la modélisation du périmètre et surtout le diagramme de contexte, qui révèle les interfaces de haut niveau entre acteurs humains, unités organisationnelles, processus métier et composants de la solution. Sur un paysage applicatif existant, la matière la plus fiable se trouve dans le système en marche: le code d'intégration, les planifications de traitements par lots, les sujets du bus de messages, les règles de pare-feu et les répertoires de dépôt de fichiers sont les interfaces que la documentation a oubliées. Le BABOK relève un second bénéfice de ce travail, souvent négligé: il fait apparaître la fréquence d'usage réelle des interfaces existantes et leurs défauts, matière qui renforce le dossier de changement.
L'identification proprement dite parcourt chaque partie prenante et chaque système qui interagit avec la solution, et liste les interfaces nécessaires à l'état futur. La relation entre une partie prenante et ses interfaces peut être plusieurs à plusieurs, parfois un à un. Le BABOK insiste sur les interfaces non évidentes, celles qui servent une fonction réglementaire, un audit ou la formation des collaborateurs. Pour chacune, quatre questions: décrire sa fonction, évaluer sa fréquence d'usage, déterminer le type d'interface approprié et éliciter les premiers détails.
Six questions structurent l'ensemble, et le BABOK les pose telles quelles: qui utilisera l'interface, quoi traverse et en quel volume, quand et à quelle fréquence, où l'échange se produit, pourquoi l'interface existe, comment elle est ou devrait être réalisée. Le produit de cette étape est une carte des interfaces, la solution au centre, ses contreparties autour, une flèche étiquetée par interface.
Spécifier une interface
Le BABOK donne cinq éléments de définition: le nom de l'interface, sa portée, la méthode d'échange entre les deux entités, le format du message et la fréquence d'échange. Il y ajoute les entrées et sorties, les règles de validation qui les gouvernent et les événements déclencheurs, en précisant que ces événements couvrent le flux nominal, les flux alternatifs et les défaillances. Cette dernière mention est celle qu'on oublie. Elle est la charnière entre une liste et un contrat.
Le gabarit se remplit rubrique par rubrique, et chaque rubrique répond à une question qui, laissée vide, deviendra un incident.
| Rubrique | La question qu'elle tranche |
|---|---|
| Toute interface | |
| Parties et sens | Qui émet, qui reçoit et l'échange est-il unidirectionnel, en requête-réponse ou bidirectionnel? |
| Déclencheur | Qu'est-ce qui déclenche l'échange: une horloge, un événement métier, une demande? Les flux alternatifs et les défaillances ont aussi le leur. |
| Données échangées | Quels champs, de quel type, obligatoires ou facultatifs, avec quelles listes de codes? C'est le point où la spécification passe la main au dictionnaire de données (BABOK 10.12): l'interface nomme le message, le dictionnaire définit chacun de ses champs. |
| Méthode et format | Par quel canal et sous quelle forme: XML sur service web, JSON sur REST, fichier signé déposé en SFTP, message ISO 20022 pain.001, code-barres imprimé sur papier. |
| Fréquence et volume | Combien de messages, à la pointe? C'est la volumétrie qui transforme une interface en un coût et en une exigence non fonctionnelle. |
| Règles de validation | Que rejette le récepteur et sur quel critère? En Suisse, c'est souvent un format imposé dont le chiffre de contrôle se vérifie sans appeler personne, comme le numéro AVS à treize chiffres, 756.XXXX.XXXX.XX. |
| Transformation | Quel côté met les deux représentations en correspondance, et qu'advient-il d'une valeur que la liste de codes de la cible ne sait pas exprimer: rejet, valeur par défaut ou perte silencieuse? Le troisième cas est le plus fréquent et le seul qui ne lève aucune erreur. |
| Comportement en erreur | Message malformé, récepteur indisponible, lot traité à moitié: y a-t-il un accusé de réception négatif, un renvoi est-il idempotent, qui est averti et sous quel délai? Sur HTTP, la RFC 9457 en donne le format canonique. |
| Propriété | Qui, nommément et de chaque côté, peut engager un changement? |
| Convention de service | Quelle disponibilité, quelle latence, quel débit, quelle rétention et à partir de quel retard un fichier devient-il un problème de conformité? |
| Sécurité et protection des données | Que traverse-t-il? Des numéros AVS et des salaires sont des données personnelles au sens de la nLPD, une propriété de l'interface. |
| Version | Quelle version du contrat fait foi, par quel canal un changement est-il annoncé et combien de temps l'ancienne version reste-t-elle acceptée en parallèle? |
| En plus, pour une interface humaine | |
| Rôles et privilèges | Qui voit quelle donnée, qui peut la modifier, qui ne peut que la consulter et par quel mécanisme ce droit est-il accordé puis retiré? |
| Flux de travail entre les systèmes | Que transporte à la main la personne qui quitte un système au milieu d'une tâche pour la terminer dans un autre? Ce trajet manuel est la partie de l'interface que personne ne spécifie. |
| Objectifs de gestion | Quelle mesure dira que l'interface fonctionne: un délai de traitement, un taux d'erreur de saisie, une charge de support? |
| Utilisabilité et accessibilité | Quelles lignes directrices de l'organisation s'imposent à la conception, en entrée? |
| En plus, pour une interface matérielle | |
| Forme et montage | Quelle géométrie, quel encombrement, quel connecteur, quelle fixation, dans quel sens? |
| Tenue en service | Quelle plage de température, quelle résistance mécanique et chimique, quelle étanchéité? |
| Medium et énergie | Quel gaz, quel liquide, à quelle pression et à quel débit? Quelle tension, quel courant et quel côté alimente l'autre? |
| Support, encodage et protocole | Quel lien physique, quel codage du signal (NRZ, Manchester), quelle trame et quel protocole (Modbus RTU, CAN, OPC UA)? |
| Sémantique du signal | Que veut dire la valeur: quelle unité, quel facteur d'échelle, quelle plage valide et quelle valeur convenue pour un capteur en défaut? |
Le BABOK est explicite sur le calendrier des interfaces humaines: elles demandent une analyse détaillée menée en amont, parce que c'est là que les défauts de conception majeurs se décident et qu'ils deviennent ensuite coûteux à reprendre. Un catalogue dont le gabarit ne sait remplir que les rubriques communes type ses écrans en interfaces utilisateur, puis les laisse vides.
La dernière étape est de valider le catalogue avec les propriétaires de chaque extrémité. Une spécification d'interface signée d'un seul côté reste un souhait.
La frontière avec les techniques voisines
Le diagramme de flux de données (BABOK 10.13) montre la donnée qui circule à travers des processus: d'où elle vient, ce qui la transforme, où elle repose, où elle aboutit. L'analyse des interfaces spécifie le contrat à une frontière entre deux systèmes ou deux organisations. Le diagramme de contexte énumère les franchissements, l'analyse des interfaces spécifie chacun d'eux et la passation est explicite dans le BABOK, qui range le diagramme de contexte parmi les entrées de la préparation. Deux asymétries achèvent de séparer les deux techniques: l'analyse des interfaces couvre aussi les interfaces utilisateur, les autorités et les appareils, qu'un diagramme de flux traite comme de simples entités externes; et un diagramme de flux ne dit rien de la fréquence, du volume, du comportement en erreur, de la propriété ni du niveau de service, qui sont toute la substance d'une spécification d'interface.
La modélisation du périmètre (BABOK 10.41) trace la ligne et place les éléments dedans ou dehors. L'analyse des interfaces spécifie chaque franchissement une fois la ligne tracée. La dépendance va dans un seul sens, et lancer l'analyse avant que le périmètre soit convenu produit un catalogue qui sera jeté.
Le diagramme de séquence (BABOK 10.42) modélise la logique d'un scénario d'usage en montrant l'information échangée entre objets, avec des lignes de vie et des messages ordonnés. La différence est temporelle: le diagramme de séquence montre l'ordre des messages dans un scénario, la spécification d'interface montre les termes permanents d'une interface, indépendamment de tout scénario. Les deux se composent: une fois l'interface spécifiée en requête-réponse avec accusé négatif, le diagramme de séquence est le support pour montrer la chorégraphie d'un appel échoué et de sa reprise.
L'interface comme source de données
Le Guide to Business Data Analytics de l'IIBA (§3.13) retourne la technique: une interface produit elle-même des données exploitables. À côté de ce que l'utilisateur saisit, le système enregistre ce qu'il fait, et ces données transactionnelles répondent à des questions que la saisie ne couvre pas. Quelles fonctions sont réellement employées. Pourquoi une demande reste inachevée. Combien de temps prend une opération de bout en bout. Où se concentrent les échecs de connexion ou les temps de chargement.
Le guide en tire une seconde conséquence pour la spécification: chaque élément d'interface se rapporte à un attribut de base de données, et écrire cette correspondance révèle les règles implicites de conservation. Une mise à jour de profil écrase-t-elle l'enregistrement, ou en crée-t-elle un nouveau que l'identifiant le plus récent désigne? Les deux se ressemblent à l'écran et se comportent différemment dans un rapport. La correspondance documentée est ce que reprennent ensuite les traitements d'extraction et de chargement.
Les pièges
L'interface que personne ne possède
Chaque côté suppose que l'autre valide, relance ou surveille. Le défaut ne se manifeste qu'en production et sa correction est organisationnelle. La colonne du catalogue qui l'évite est un propriétaire nommé de chaque côté: le nom d'une personne et son rôle. Quand la contrepartie est un fournisseur sans interlocuteur désigné, la sortie est l'escalade contractuelle.
Le champ non documenté qui porte du sens
Une zone de référence libre dans laquelle quelqu'un, il y a des années, a commencé à écrire un code dont un traitement en aval dépend aujourd'hui. Il ne figure dans aucun schéma ni dans aucun dictionnaire, et il casse le jour où le champ est assaini. Les interfaces accumulent ces passagers clandestins. C'est la raison de spécifier champ par champ.
Le lot qui perd des enregistrements en silence
Le récepteur charge le fichier enregistrement par enregistrement et écarte ceux qu'il ne sait pas lire. Sur un lot de 4'812 enregistrements, 4'796 sont chargés et 16 sont écartés, aucune erreur ne remonte à l'émetteur, personne ne compte. La réponse de la spécification est un contrat de réconciliation: l'émetteur annonce le nombre émis, le récepteur accuse réception du nombre chargé, un écart est un incident. Une interface sans accusé de réception laisse son comportement en erreur à l'espoir.
Le comportement en erreur supposé de l'autre côté
Le contrat de réconciliation posé, le récepteur rapporte désormais ses 16 rejets, et le défaut se déplace d'un cran. La reprise de l'émetteur a été construite en supposant que le récepteur rejette le fichier entier dès qu'un enregistrement est malformé: elle renvoie donc le fichier entier après correction et duplique les 4'796 enregistrements déjà chargés. Le récepteur accepte enregistrement par enregistrement, l'émetteur a supposé l'inverse et aucun des deux comportements n'a jamais été écrit. Le rejet global ou l'acceptation partielle est une décision, et l'effet d'un renvoi, remplacement ou doublon, en est une autre: elles appartiennent à la spécification.
La volumétrie laissée vide
L'interface est identifiée, nommée, typée, et personne n'a demandé combien. Le dimensionnement, la convention de service et le chiffrage reposent alors sur une intuition.
La dérive du contrat
L'autre côté modifie le contrat et l'on s'en aperçoit à un rejet. L'exemple suisse est daté et public: les directives de mise en œuvre de la QR-facture sont passées en version 2.3 le 21 novembre 2025, laquelle exige des adresses structurées dans le Swiss QR Code et n'admet plus la forme combinée, la version 2.4 entrant en vigueur le 14 novembre 2026. Tout système de facturation qui traitait l'adresse comme du texte libre avait un changement d'interface imposé de l'extérieur, à date connue, à absorber. Une spécification sans version ni canal d'annonce est un instantané.
Le format spécifié, le sens supposé
Deux systèmes conviennent qu'un champ est une chaîne de treize chiffres et divergent sur ce qu'il identifie. L'accord sur le format laisse l'accord sémantique à faire, et celui-ci vit dans les listes de codes, dans la table de correspondance de la transformation et dans les définitions du dictionnaire de données.
Le catalogue réduit aux interfaces techniques
Les six types du BABOK comprennent les interfaces utilisateur, les personnes externes dont les autorités publiques et les processus métier. La déclaration réglementaire et le passage de main entre deux services ont un format, une échéance et un mode de défaillance, exactement comme un service web.
Considérations IA
Le meilleur emploi est la dérivation d'un catalogue candidat depuis ce qui tourne. Pointer un modèle sur des schémas OpenAPI, WSDL ou XSD, sur le code d'intégration, sur les définitions de traitements ETL, sur la configuration du bus de messages et sur les règles de pare-feu, puis lui faire extraire un premier jet dans les colonnes retenues. Sur un paysage hérité que personne n'a documenté depuis dix ans, cela remplace la page blanche par un brouillon à réfuter, et la réfutation se mène contre le système en marche.
Deux autres emplois sont solides. Le diff de schémas et l'analyse d'impact: deux versions d'un XSD ou d'un document OpenAPI et la question de savoir lesquels des champs réellement utilisés ont changé. La tâche est mécanique, exhaustive et le genre de vigilance que la relecture humaine perd au quatre-centième élément; elle transforme une note de version fournisseur en une liste de travaux. La génération de charges utiles d'exemple et de cas de test négatifs depuis un schéma: message malformé, valeur aux bornes, champ obligatoire absent, code hors liste. Les chemins d'échec sont la partie d'une interface la moins testée et la plus spécifiée, et les engendrer depuis le contrat coûte peu. La matrice de comportement en erreur se prérédige de même depuis les codes de statut et le modèle d'erreur déclarés par une API.
Trois limites tiennent au jugement et à la loi. La volumétrie, la fréquence, la propriété et le niveau de service ne figurent dans aucun schéma: ce sont des propriétés de l'organisation, si bien qu'un modèle interrogé produira un nombre vraisemblable. Un volume fabriqué est pire qu'une case vide, parce qu'on dimensionnera dessus. La sémantique d'une liste de codes vient des deux propriétaires: un modèle dira qu'un champ énumère onze valeurs, seul le métier dira lesquelles servent encore, laquelle est systématiquement mal employée et vers quoi chacune se traduit dans la liste de la cible. La protection des données, enfin: un message ELM porte des numéros AVS, des salaires et le numéro IDE de l'employeur, donc des données personnelles au sens de la nLPD. Le travail se fait sur le schéma et sur des charges utiles synthétiques. Un extrait de production collé dans un modèle généraliste est exclu.
Exemples
Le paysage retenu est celui des interfaces salariales d'une PME suisse de 120 collaborateurs, autour du logiciel de salaires. Sur ces 120 collaborateurs, 34 sont imposés à la source (permis B et frontaliers), et la comptabilité répartit la masse salariale sur quatre centres de coût: ces deux nombres, avec l'effectif, sont les seules entrées dont dépendent tous les volumes du catalogue. Le paysage porte huit interfaces, cinq des six types du BABOK, cinq formats et quatre rythmes (événementiel, mensuel, annuel, tous les deux ans), et il fait apparaître l'autorité publique et le passage de main entre processus comme des contreparties ordinaires.
La carte porte le contrat de chaque flux en trois signes: le sens, le format, le rythme. Le catalogue déplie les mêmes huit interfaces en colonnes et ajoute ce que la carte ne peut pas porter, le volume et le propriétaire de chaque extrémité.
| Id | Interface | Sens | Contrepartie | Type (BABOK) | Méthode et format | Déclencheur et fréquence | Volume (pointe) | Propriétaires (émetteur / récepteur) |
|---|---|---|---|---|---|---|---|---|
| IF-01 | Déclaration de salaires ELM | sortant | Caisse de compensation AVS | Personne externe (autorité) | XML Lohnstandard-CH, service web (procédure PIV) | Clôture annuelle des salaires, 1 envoi par an | 120 enregistrements, un par collaborateur | Responsable des salaires / interlocuteur technique de la caisse |
| IF-02 | Déclaration de l'impôt à la source | sortant | Administration fiscale cantonale | Personne externe (autorité) | XML Lohnstandard-CH | Validation du décompte mensuel, 12 envois par an | 34 enregistrements, les 34 collaborateurs imposés à la source sur 120 | Responsable des salaires / service cantonal de l'impôt à la source |
| IF-03 | Déclaration de la masse salariale LAA | sortant | Assureur-accidents | Personne externe (assureur) | XML Lohnstandard-CH | Clôture annuelle, 1 envoi par an | 120 enregistrements | Responsable des salaires / gestionnaire de police |
| IF-04 | Enquête suisse sur la structure des salaires (ESS) | sortant | Office fédéral de la statistique | Personne externe (autorité) | XML Lohnstandard-CH | Relevé fédéral, 1 envoi tous les deux ans | 120 enregistrements | Responsable des salaires / service de l'enquête |
| IF-05 | Ordre de paiement des salaires | sortant | Banque | Données entre systèmes | ISO 20022 pain.001, dépôt e-banking | Validation de la paie, 13 exécutions par an: le 13e salaire part en exécution séparée en décembre | 120 transactions par exécution; pointe à 240 transactions en décembre, qui porte deux exécutions | Responsable des salaires / support e-banking de la banque |
| IF-06 | Données du personnel | entrant | Système RH | API | JSON sur REST, appel synchrone | Événementiel (embauche, mutation, sortie), environ 8 par mois | 1 enregistrement par événement | Responsable RH / responsable des salaires |
| IF-07 | Certificat de salaire | sortant | Collaborateur | Interface utilisateur | PDF, portail collaborateur | Après clôture annuelle, 1 par collaborateur | 120 documents | Responsable des salaires / collaborateur |
| IF-08 | Écriture de salaires | sortant | Comptabilité (processus comptable) | Processus métier | Fichier CSV d'écritures collectives, dépôt sur un répertoire partagé | Validation de la paie, 12 envois par an: le 13e salaire est comptabilisé dans la période de décembre | 4 écritures collectives par envoi, une par centre de coût | Responsable des salaires / comptable |
Le catalogue s'arrête là où le contrat commence. La spécification développe une seule ligne, IF-01, et les rubriques qui la distinguent du catalogue sont les plus pénibles à remplir: le comportement en erreur, le propriétaire habilité à engager sa partie, la convention de service et la version.
| Rubrique | IF-01, Déclaration de salaires ELM |
|---|---|
| Portée | Masse salariale annuelle de tous les collaborateurs assujettis à l'AVS, pour un exercice. |
| Parties et sens | Logiciel de salaires (émetteur) vers la caisse de compensation AVS (récepteur). Sortant, avec réponse: accusé de réception et rapport de traitement. |
| Méthode d'échange | Service web, procédure PIV du standard Swissdec. Repli prévu: procédure EIV (export d'un fichier, dépôt manuel sur le portail du destinataire) si le service web est indisponible à l'échéance. |
| Format du message | XML conforme à la déclaration Lohnstandard-CH. Le logiciel est certifié Swissdec pour la version du standard en vigueur au moment de l'envoi. |
| Champs pivots | Numéro AVS du collaborateur, 13 chiffres, 756.XXXX.XXXX.XX. Numéro IDE de l'employeur, CHE-NNN.NNN.NNN. Période de décompte, montants soumis par catégorie de cotisation. |
| Règles de validation | Chiffre de contrôle du numéro AVS et du numéro IDE vérifié avant émission. Le numéro AVS ne se génère pas: il est attribué par la Centrale de compensation, et un collaborateur sans numéro bloque la ligne. |
| Transformation et correspondance | Les genres de salaire du logiciel sont mis en correspondance avec les rubriques du standard, du côté de l'émetteur, avant émission. Décidé par le projet: un genre de salaire interne sans correspondance dans le standard bloque l'envoi et remonte au responsable des salaires. |
| Déclencheur | Clôture annuelle des salaires. Déclencheur secondaire: renvoi d'un enregistrement corrigé après rejet. |
| Fréquence et volume | 1 envoi par an, 120 enregistrements, un par collaborateur. Pas de pointe. |
| Comportement en erreur | Imposé par le standard et à lire dans la documentation Swissdec: la granularité du rejet, le contenu du rapport de traitement retourné par la caisse et l'effet d'un renvoi après correction (remplacement de l'enregistrement ou doublon). La spécification les recopie. Décidé par le projet: le contrat de réconciliation, l'émetteur rapproche le nombre d'enregistrements émis du nombre accusé et traite tout écart comme un incident; et l'escalade, un rejet non traité sous 5 jours ouvrables remonte au responsable des salaires. |
| Propriétaires | Émetteur: le responsable des salaires, nommément. Récepteur: l'interlocuteur technique désigné au contrat d'affiliation à la caisse. Chacun peut engager un changement de son côté. |
| Convention de service | Imposé par la loi: la déclaration est due à date fixe, et un dépassement est un problème de conformité avec des conséquences réglementaires. Décidé par le projet: l'envoi est préparé et contrôlé au plus tard cinq jours ouvrables avant l'échéance. |
| Sécurité et protection des données | Le message porte des numéros AVS et des salaires, donc des données personnelles au sens de la nLPD. Transport chiffré, accès restreint aux deux rôles nommés, aucune extraction de production hors du périmètre. |
| Version et changement | Version du standard pour laquelle le logiciel est certifié. Canal d'annonce: les publications de Swissdec. À établir à chaque montée de version: la durée pendant laquelle l'ancienne version reste acceptée en parallèle. |
Coût
| Phase | Niveau | Justification |
|---|---|---|
| Préparation | Moyen | Rassembler la matière existante (diagramme de contexte, inventaire d'intégration, preuves tirées du système en marche) est borné. Trouver, de l'autre côté, une personne habilitée à engager sa partie est ce qui coûte du temps. |
| Exécution | Moyen | L'identification est rapide et tient dans un atelier lorsqu'un diagramme de contexte existe. La caractérisation de chaque interface (volume, transformation, comportement en erreur, niveau de service, propriétaire) dépend de la contrepartie, et la durée de la technique suit sa disponibilité. |
| Documentation | Élevé | La spécification est le contrat: elle se versionne et se tient à jour à chaque changement de l'un ou l'autre côté. Ce poste décide si la technique tient dans la durée. C'est aussi le premier abandonné. Une spécification qui a dérivé de l'interface réelle est nuisible, parce qu'on lui fait confiance. |
Outils
Le tableur ou la table de wiki est le domicile honnête du catalogue quand le paysage est petit, où vivent la plupart des catalogues réels. Les outils de gestion des exigences (Jama, Polarion, DOORS) prennent le relais lorsque la spécification a une valeur contractuelle et que les interfaces doivent être tracées jusqu'aux exigences et aux tests.
Les formats de contrat sont la spécification sous forme lisible par machine, et les adopter est le seul moyen connu d'empêcher la spécification de dériver de la réalisation: OpenAPI pour les API REST sur HTTP, AsyncAPI pour les échanges par événements et par messages, WSDL et XSD pour SOAP (qu'emploie la procédure PIV de Swissdec) et JSON Schema pour la validation des charges utiles. Les tests de contrat (Pact) et les clients d'API (Postman, SoapUI) rendent la spécification exécutable: la chaîne d'intégration détecte alors la dérive avant la mise en production. Les passerelles d'API et les portails développeurs sont l'endroit où le catalogue et le contrat sont publiés au côté consommateur.
Pour la carte, un outil de modélisation suffit: une vue de coopération applicative en ArchiMate ou un diagramme de conteneurs C4 se tiennent à l'altitude de la carte des interfaces. Reste la documentation des standards eux-mêmes, qui pour une interface suisse est souvent la spécification qu'on n'a pas le droit d'écrire: Swissdec pour ELM, SIX pour les Swiss Payment Standards, l'IBAN et la QR-facture, eCH pour les échanges de la cyberadministration, le Forum Datenaustausch pour la facturation entre fournisseurs de soins et assureurs. Lire le contrat imposé est le travail.
Sources
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.24 Interface Analysis: la définition, les six types d'interface, les trois éléments de la technique, ses forces et sa limite.
- ISO/IEC/IEEE 29148:2018, Systems and software engineering, Life cycle processes, Requirements engineering: la norme qui porte les exigences d'interface externe dans la spécification des exigences système.
- NASA Systems Engineering Handbook, §6.3 Interface Management: la famille des documents d'interface (IRD, ICD, IDD).
- OpenAPI Specification, OpenAPI Initiative: le contrat d'interface HTTP sous forme lisible par machine.
- AsyncAPI Specification, AsyncAPI Initiative: le même contrat pour les échanges par événements et par messages.
- RFC 9457, Problem Details for HTTP APIs, IETF: une convention canonique de comportement en erreur à une interface HTTP.
- Swissdec, Lohnstandard-CH (ELM): le standard suisse de déclaration de salaires, la distinction entre déclaration et procédure, les procédures PIV et EIV, la certification des logiciels.
- ISO 20022: le standard de messagerie financière derrière les Swiss Payment Standards et le message
pain.001. - SIX, QR-facture et Swiss Payment Standards: les directives de mise en œuvre et leur versionnage, dont le passage aux adresses structurées.
- SIX, IBAN: le standard de l'IBAN suisse et de l'identifiant de banque IID, tenu par SIX.
- Office fédéral de la statistique, Numéro d'identification des entreprises (IDE): le format
CHE-NNN.NNN.NNNet son chiffre de contrôle. - Office fédéral de la statistique, Enquête suisse sur la structure des salaires (ESS): le relevé fédéral conduit tous les deux ans, que le domaine statistique d'ELM alimente.
- OFAS, Les éléments qui composent le numéro d'assuré AVS: le format
756.XXXX.XXXX.XX, ses 13 chiffres et son chiffre de contrôle. - Loi fédérale sur la protection des données (nLPD), RS 235.1: le régime applicable aux données personnelles que porte une interface salariale, en vigueur depuis le 1er septembre 2023.
- eCH: les normes d'échange de la cyberadministration suisse.
- Forum Datenaustausch, standards XML: les standards d'échange de la facturation entre fournisseurs de soins et assureurs.
- IIBA, Guide to Business Data Analytics, §3.13 Interface Analysis: l'interface comme productrice de données transactionnelles et la correspondance entre éléments d'interface et attributs de base de données.
- Confédération suisse, Chancellerie fédérale, HERMES 2022, Manuel de référence Gestion de projet, résultat 4.4.1.18 Concept d'intégration: les objets d'intégration et les interfaces comme rubrique exigée du document qui décrit l'intégration du système dans son environnement.
- HERMES 2022, Manuel de référence Gestion de projet, Confédération suisse, Chancellerie fédérale, §A.5 Les interfaces de la gestion de projet HERMES: l'interface au sens organisationnel, la compatibilité garantie entre l'organisation de projet et l'organisation permanente (Stammorganisation), le reporting comme exemple et les trois rôles indispensables au fonctionnement des interfaces.