Une spécification formelle consignant les détails techniques, formats de données, protocoles, caractéristiques électriques/mécaniques/temporalité, sens sémantique, gestion d'erreur, gestion des versions et responsabilités pour une interface entre éléments système ; elle sert de référentiel contractuel et de base pour la conception, la vérification et le contrôle des modifications.

Principe

Un ICD agit comme le contrat technique contrôlé d'une interface : toute modification du comportement, des formats ou des responsabilités d'interface doit être gérée via le processus de configuration et de contrôle des modifications de l'ICD pour préserver la compatibilité entre éléments développés indépendamment.

Démonstration

Scénario illustratif — Situation : Une équipe bus satellite et une équipe charge utile doivent échanger télémétrie et commandes. Reconnaissance : Elles rédigent un ICD précisant les ID de message, structures de paquets, fenêtres temporelles et réponses d'erreur. Action : Lors de l'intégration, une inversion d'octets est détectée ; les équipes suivent la procédure de changement de l'ICD pour convenir d'une révision, mettre à jour les tests et redéployer le firmware. Conséquence : La modification est traçable, les tests de régression sont actualisés et la compatibilité rétablie sans correctifs ad hoc pendant les tests d'intégration.

Mauvaise application

Utiliser un ICD comme document indicatif ou résumé informel par email plutôt que comme base contrôlée. L'erreur consiste à supposer que des détails d'interface non documentés ou convenus verbalement seront conservés entre équipes et calendriers indépendants.

Conséquence

Un ICD correctement maintenu réduit le risque d'interopérabilité, permet un développement indépendant et une vérification formelle, et fournit la traçabilité nécessaire pour la certification et la gestion de configuration ; un ICD manquant ou mal maintenu augmente la probabilité d'implémentations incompatibles, d'échecs d'intégration tardifs et de reprises coûteuses.

Inversion

Pour le prototypage rapide, les expériences exploratoires ou les prototypes jetables, des processus ICD lourds peuvent être contre‑productifs ; de même, pour des interfaces conçues pour être rétrocompatibles et versionnées par négociation à l'exécution (p. ex. API robustas), un contrôle des changements trop rigide peut freiner l'évolution itérative.

Limite

Clairement inclus : spécifications d'interface définitives et contrôlées incluant formats de données, sémantique, temporisation, connecteurs physiques, comportement en erreur et gestion des versions. Cas limite : documentation d'API qui décrit les appels mais sans contrôle de configuration ni responsabilités convenues. Clairement exclu : énoncés d'exigences de haut niveau qui ne spécifient pas les formats ou comportements d'interface.

Tension sémantique

Spécificité formelle et contrôle des modifications au niveau contractuel (réduction du risque d'intégration) versus flexibilité et vitesse de l'évolution itérative des interfaces (favorisant l'innovation rapide).

Synthèse

L'ICD transforme les hypothèses techniques d'interface en un contrat traçable ; son efficacité dépend d'une propriété claire, d'une discipline de gestion des versions et de son couplage aux artefacts de vérification (tests et montages).