Merci beaucoup pour ces explications Damien. Je trouve cette discussion super intéressante car je viens de me rendre compte qu’on utilise les mêmes mots pour parler de choses différentes et cela est lié surement au croisement de cultures.
J’ai l’impression que cela est le cas pour « services » (diffèrent pour moi des fonctions du système) et « architecture ».
Par exemple lorsque je parle d’architecture je ne me réfère pas à l’architecture du cloud mais à celle du système de télécom par satellites (segment sol, segment spatial, segment utilisateur, etc…) qui contribue à assurer un ensemble de fonctions du cloud (ça correspond à une partie des services de l’architecture cloud? 
) .
Je suis complètement d’accord sur le fait qu’il faut commencer par identifier tous les cas d’usage possibles et leurs utilisateurs (même si j’ai la tendance à penser qu’il s’agit à 90% de ceux qui existent pour le cloud terrestre et que la partie spatiale doit être vue à comme une partie d’une infrastructure plus large).
Par contre je pense qu’il faut commencer à réfléchir sur comment passer de ces cas d’usage à la structuration du projet pour permettre au maximum de personnes de participer. Il ne s’agit pas de définir l’architecture du cloud mais de bâtir la méthodologie qui permettra de descendre de plus en plus dans le détail du système (Trade off cas d’usage -> trade-off architecture cloud & trade off gouvernance -> trade off architecture système de télécom par satellites -> Trade off sous-systèmes ->etc.).
Il s’agit donc de formaliser le processus d’ingénierie système. Ce sujet a déjà un peu été abordés sur le forum (Méthode de conception : Model Based System Engineering)