Analyse systémique en informatique

L'analyse systémique en informatique (Systems Analysis and Design) est une approche de la conception et du développement de systèmes d'information, de la conception à l'exploitation, qui inclut l'identification des besoins, la formalisation des exigences, la modélisation du domaine et des processus, ainsi que l'évaluation des alternatives et des risques. En d'autres termes, l'analyse systémique en informatique est l'étape du développement au cours de laquelle les spécialistes étudient une problématique, définissent ce que le système doit faire et conçoivent des solutions pour sa création.

L'analyse systémique classique couvre un large éventail de domaines d'application, non seulement le développement de logiciels, mais aussi les changements organisationnels, les stratégies et d'autres aspects.[1] [2]

Objet et tâches de l'analyse systémique en informatique

L'objet de l'analyse systémique en informatique est le système d'information (produit logiciel et/ou service) tout au long de son cycle de vie — de la conception et de la justification à la mise en œuvre et à l'exploitation.

La tâche de l'analyse systémique est de transformer les besoins métier en un ensemble cohérent et vérifiable d'exigences et de solutions architecturales : identifier et documenter les objectifs et les contraintes des parties prenantes, formaliser les exigences, modéliser le domaine et les processus, évaluer la faisabilité et les risques des alternatives, et justifier l'architecture choisie. Le résultat est la création de documents concertés et l'établissement de liens traçables entre les exigences, les décisions de conception et les tests. Cela garantit la gouvernabilité et le contrôle du processus de développement.

Les tâches de l'analyse systémique incluent :

• Identification des besoins et des objectifs des parties prenantes. L'analyste recueille et précise les attentes des clients, des utilisateurs et des autres parties intéressées ; il utilise pour cela des entretiens, des sondages, l'observation et l'analyse des processus actuels. Le résultat est une première spécification des exigences qui distingue les exigences fonctionnelles (« ce que le système doit faire ») et non fonctionnelles (fiabilité, performance, sécurité, etc.).

• Formalisation et documentation des exigences. Les demandes sont transformées en exigences vérifiables. Une exigence bien formulée doit être claire et non ambiguë, complète, cohérente, vérifiable et traçable jusqu'aux objectifs de plus haut niveau ; l'ensemble des exigences doit être cohérent et intégré. Dans la pratique, on utilise des documents standardisés : la SRS (Software Requirements Specification) selon la norme ISO/IEC/IEEE 29148, ainsi que, dans certains secteurs, l'URS (User Requirements Specification) et les spécifications fonctionnelles.

• Analyse et modélisation du système. Pour comprendre comment le système fonctionnera et interagira avec le monde extérieur, des modèles sont construits : diagrammes de cas d'utilisation (Use Case) pour les scénarios d'utilisation, DFD pour les flux de données et les processus métier, diagrammes de classes/composants, etc. Les modèles servent de base à la comparaison des solutions et architectures alternatives.

• Évaluation de la faisabilité et sélection de la solution. Une étude de faisabilité (feasibility study) est menée (faisabilité technique, organisationnelle, économique, calendaire) ainsi qu'une comparaison des alternatives architecturales (trade-off). Pour évaluer la qualité de l'architecture selon des attributs (par ex., performance, scalabilité, modifiabilité), des méthodes comme l'ATAM (Architecture Tradeoff Analysis Method) sont utilisées. Le choix entre, par exemple, une architecture monolithique et une architecture microservices [3] repose sur des compromis explicites (complexité d'exploitation vs scalabilité indépendante et vitesse de livraison) en se basant sur les recommandations des guides de l'industrie.

• Préparation des artefacts de projet. À l'issue de l'analyse, les éléments suivants sont produits :
  • la spécification des exigences approuvée (avec indication de leur importance),
  • le modèle conceptuel du système (diagrammes/descriptions),
  • les décisions architecturales et de conception (schémas de données, interfaces des systèmes externes),
  • le plan de mise en œuvre (étapes/modules).
  • Il est crucial d'assurer la traçabilité (bidirectional traceability) des exigences vers les éléments de conception et les tests.

Le succès d'un projet informatique dépend en grande partie de la maturité des pratiques de gestion des exigences et de l'architecture. Une étude menée par McKinsey et Oxford a montré que les grands projets informatiques dépassent souvent leur budget et leurs délais. Cette étude a également souligné l'importance de bien gérer la stratégie, d'interagir avec les parties prenantes et de recueillir intelligemment les exigences. Tous ces éléments peuvent fortement influencer la réussite ou l'échec d'un projet.

Approches et méthodologies en analyse systémique informatique

L'analyse systémique en informatique s'appuie sur les principes de la pensée systémique et sur des méthodologies adaptées au développement de logiciels. Dans la pratique, on combine des approches « dures » et « douces », des méthodologies structurelles, des notations orientées objet, ainsi que des langages de modélisation de processus et d'exigences.

• Approches « dures » et « douces ». Dans les projets informatiques, l'approche dure (hard systems) suppose des objectifs et des exigences formalisables à l'avance, une décomposition et une conception « de haut en bas ». L'approche douce (soft systems) est utilisée lorsque les objectifs sont flous et que les points de vue sont multiples : on utilise des éléments de la Soft Systems Methodology (SSM) (par ex., rich picture, définitions racines, CATWOE) pour s'accorder sur la compréhension du problème et les changements souhaités ; les résultats sont ensuite traduits en exigences formelles.

• Méthodologie SSM (Soft Systems Methodology). Initialement développée par Peter Checkland pour les changements organisationnels, la SSM est utile dans les phases pré-projet en informatique : de l'étude de la situation problématique et de la formulation des définitions racines (y compris via CATWOE) à la comparaison des modèles conceptuels avec la réalité et à l'atteinte d'un accord entre les parties prenantes.

• Méthodologies structurées : SADT/IDEF0. SADT modélise le système comme une hiérarchie de fonctions ; la notation standard IDEF0 (IEEE 1320.1) formalise les fonctions et leurs interfaces I-C-O-M (Inputs, Controls, Outputs, Mechanisms). Cette méthode est pratique pour la décomposition fonctionnelle et pour définir les frontières du système indépendamment des algorithmes.

• Analyse orientée objet : UML et SysML (MBSE). L'UML est devenu le langage de base pour les exigences et la conception (diagrammes de cas d'utilisation, de classes, de séquences, etc.) et facilite la validation des scénarios avec les utilisateurs ; SysML étend l'UML pour l'ingénierie système (diagrammes d'exigences, diagrammes paramétriques) et s'appuie sur l'approche MBSE, où le modèle est l'artefact central à travers toutes les étapes, des exigences aux tests.

• Modélisation des processus métier : BPMN. La norme BPMN est utilisée pour décrire graphiquement les processus (pools, flux de travail, événements, passerelles), y compris pour la comparaison as-is/to-be dans les spécifications d'exigences et d'intégration.

• Lien avec l'ingénierie des exigences. Le processus comprend les étapes d'elicitation–analysis–specification–validation–change management ; les critères d'une « bonne exigence » et la structure de la SRS sont réglementés par la norme ISO/IEC/IEEE 29148. Pour la priorisation, des techniques comme MoSCoW (Must/Should/Could/Won’t) et des méthodes de choix multicritères, comme l'AHP, sont utilisées. Dans les processus agiles, l'activité d'analyse systémique se reflète dans l'affinage du backlog (backlog refinement) et la traçabilité des exigences.

• Lien avec l'ingénierie système. Pour les systèmes complexes (cyber-physiques), on utilise le modèle en V : sur la branche « gauche » se trouvent l'analyse système et l'architecture, sur la branche « droite » l'intégration, la vérification et la validation, avec un lien vers les artefacts de la branche gauche. Les méthodes d'évaluation de l'architecture par attributs qualitatifs incluent l'ATAM (analyse des compromis).

L'analyse systémique en informatique combine des approches éprouvées — des méthodologies douces pour aligner les visions aux notations et normes formelles. Le choix des outils dépend du degré de certitude de la tâche : en cas de forte incertitude, le rôle de la SSM et de la facilitation est renforcé ; lorsque les frontières sont claires, les modèles formels (UML/SysML, IDEF0, BPMN) et les réglementations prévalent.

Lien avec l'architecture informatique et l'architecture d'entreprise

L'analyse systémique dans les projets informatiques est étroitement liée à la conception architecturale. Les rôles de l'analyste et de l'architecte se chevauchent : l'analyste formule les exigences et le modèle logique, tandis que l'architecte définit la structure cible de la solution et les compromis techniques ; leur travail est mené conjointement.

• Architecture des systèmes informatiques. Au sens strict, l'architecture logicielle est l'organisation des composants, leurs relations et les principes qui guident la conception de la solution. Il est important pour l'analyste de tenir compte des styles architecturaux (en couches, client-serveur, microservices, événementielle, etc.), car les exigences non fonctionnelles (fiabilité, scalabilité, modifiabilité) déterminent souvent les décisions architecturales et leurs compromis. À un stade précoce de l'analyse, une vision architecturale de haut niveau (high-level vision) est formulée et une ébauche de la solution est élaborée pour vérifier la viabilité des exigences (la durée des itérations et le niveau de détail dépendent de la méthodologie).

• Patrons et solutions préliminaires. Pour satisfaire les exigences non fonctionnelles, des patrons d'architecture (architectural patterns) sont utilisés. Par exemple, pour une interaction asynchrone et un couplage faible, on utilise le patron publication-abonnement via un broker de messages dans une architecture événementielle.

• TOGAF (The Open Group Architecture Framework). L'un des cadres d'architecture d'entreprise les plus répandus ; il comprend la méthode ADM (Architecture Development Method) et des artefacts pour la gestion de l'architecture (référentiel, catalogues/matrices, principes). Dans TOGAF, la gestion des exigences est un processus transversal, intégré à toutes les phases de l'ADM. Pour supporter les exigences et la traçabilité, on utilise des catalogues et des matrices (par ex., exigences ↔ services, fonctions ↔ composants), et on distingue les Architecture Building Blocks et les Solution Building Blocks. Les principes et les normes de l'entreprise sont consignés dans des catalogues correspondants et agissent comme des exigences non fonctionnelles externes pour les équipes de projet. La conformité des solutions à l'architecture cible est confirmée par une procédure de revue de conformité architecturale (Architecture Compliance Review). L'approche TOGAF suppose une Architecture Vision préliminaire suivie d'une spécification détaillée (données/applications/technologies) avec un plan de migration et une gestion des changements d'exigences.

• Zachman Framework. Une ontologie précoce et influente des artefacts d'architecture d'entreprise, présentée sous forme de matrice 6×6 (perspectives × aspects « quoi/comment/où/qui/quand/pourquoi »). La ligne « concepteur » correspond à l'analyse et à la conception système ; les colonnes définissent l'exhaustivité de l'examen des données, des fonctions/processus, des rôles, de l'emplacement et de la motivation. Le cadre sert de classification (et non de méthodologie) et aide à garantir la complétude de la description de la solution dans le paysage de l'entreprise.

• Lien avec l'architecture d'entreprise (Enterprise Architecture, EA). L'analyste système travaille dans le contexte de l'EA : les nouvelles exigences sont tracées jusqu'aux capacités métier et au modèle opérationnel ; les normes et les contraintes de principe de l'entreprise (sécurité, compatibilité, etc.) sont appliquées. Au stade de l'initiation, une Architecture Vision est formulée (objectifs/contraintes, exigences de haut niveau), puis l'analyste détaille, en maintenant la traçabilité avec la vision et les normes d'entreprise ; le non-respect des normes est identifié lors des revues d'architecture et peut conduire à des modifications de la solution.

En résumé : l'analyse systémique et la conception architecturale forment un duo « exigences → décisions architecturales → compromis sur les attributs de qualité ». Le choix des méthodes (styles/patrons, artefacts TOGAF, classification Zachman) est déterminé par la nature du projet et le cadre de l'architecture d'entreprise.

Processus et pratiques

L'analyse systémique s'intègre dans tout le cycle de vie du développement et de l'exploitation des logiciels, reliant les objectifs métier, l'architecture et la livraison. Elle comprend l'étude pré-projet, le choix de l'approche, la création d'artefacts vérifiables et les exigences de fiabilité, de performance, de sécurité et de maintenance. Dans le modèle en cascade, l'analyse est effectuée avant la conception et la mise en œuvre ; dans les méthodes agiles, elle est continue à travers les itérations ; et dans le DevOps, l'accent est mis sur les objectifs opérationnels. Quelle que soit l'approche, l'analyse garantit la traçabilité, la gestion des changements et des risques, la documentation des compromis architecturaux et le respect des contraintes réglementaires, rendant le développement prévisible et maîtrisable.

• SDLC classique (Waterfall). L'étape d'Analyse Système et de Définition des Exigences précède la conception et la mise en œuvre ; les exigences sont fixées dans une SRS détaillée qui sert de base à la planification et aux contrats. Efficace dans les domaines stables et réglementés ; les risques de « gel » des exigences sont réduits par des SRR/revues et une gestion des changements via un CCB.

• Méthodologies agiles (Agile). L'analyse est continue : au lieu d'une SRS finale, on maintient un backlog de produit composé de user stories avec des critères d'acceptation, affiné lors du backlog refinement ; on utilise le BDD (Given–When–Then) ; le risque de perdre une architecture cohérente est compensé par une conception architecturale précoce et une traçabilité transparente des exigences ↔ mise en œuvre/tests.

• DevOps et SRE. Les livraisons fréquentes exigent des exigences opérationnelles « par défaut » : automatisation, observabilité, rollback. Les exigences non fonctionnelles sont formulées en termes de SLO/SLI, on gère un budget d'erreur (error budget) ; des tâches pour les logs/métriques/traces/alertes sont ajoutées au backlog ; pour des déploiements sans interruption, on utilise les patrons blue/green et autres.

• Gestion des exigences et des risques. Les exigences dans un ALM ont des statuts et des liens avec les tâches/livraisons/défauts ; le contrôle de version, l'analyse d'impact des changements et la repriorisation régulière sont obligatoires.

• Assurance qualité (QA). La qualité est intégrée dès la phase des exigences : revues, « Three Amigos », plan de test d'acceptation (Acceptance Test Plan), tests automatisés des critères d'acceptation (BDD/ATDD).

• Observabilité et fiabilité. Les exigences incluent des SLA/SLO, MTTR et MTBF avec des objectifs mesurables et des méthodes de contrôle ; ces paramètres proviennent du métier/de l'exploitation et sont intégrés dans l'architecture et les tests de fiabilité.

Métriques et qualité des artefacts

Pour évaluer le travail de l'analyste système et la qualité de ses résultats, on utilise des critères reconnus. Des exigences et des modèles de qualité sont la base d'un projet réussi, c'est pourquoi ils sont gérés tout au long du cycle de vie (elicitation → specification → verification/validation → change management). Les attributs de qualité de base des exigences sont définis dans les normes ISO/IEC/IEEE 29148 et (historiquement) IEEE 830.

• Correction (Correctness) — l'exigence reflète un besoin authentique et est validée par les experts du domaine ; elle est confirmée par la validation (revue/inspection, prototypes, scénarios).

• Complétude (Completeness) — les aspects et conditions essentiels sont pris en compte.
  • Complétude d'une exigence individuelle : les détails nécessaires sont spécifiés (par ex., « l'indicateur passe au statut rouge en cas d'échec », et non simplement « devient rouge »).
  • Complétude de la spécification : les scénarios/rôles sont couverts, les NFR sont définis ; ceci est atteint grâce à des listes de contrôle et à la traçabilité vers les objectifs métier ; un audit indépendant de la complétude est utile (QA/revue).

• Absence d'ambiguïté (Unambiguity) — les formulations sont interprétées de manière unique ; un glossaire, des modèles du type « le système doit faire A, lorsque B, si C » et des exemples aident ; les diagrammes sont accompagnés d'une légende. La vérification se fait par le principe des « quatre yeux ».

• Cohérence (Consistency) — les exigences ne se contredisent pas entre elles ni avec les contraintes externes ; on utilise la structuration, des tableaux récapitulatifs d'attributs, des revues d'équipe ; on vérifie la conformité avec la réglementation/les normes.

• Vérifiabilité/testabilité (Verifiability) — la réalisation est confirmée par un test/une démonstration/une analyse ; les formulations non vérifiables sont remplacées par des critères mesurables ; pour les NFR, des métriques sont définies et les critères d'acceptation sont fixés à l'avance.

• Modifiabilité et traçabilité (Modifiability & Traceability) — des identifiants uniques, une structure logique (« une idée, un paragraphe »), l'absence de doublons ; les liens « exigence ↔ source/objectif/conception/test » sont maintenus, une matrice de traçabilité (RTM) est tenue à jour.

• Classement et priorisation — qualité de l'ensemble des exigences ; on utilise des techniques comme MoSCoW et MCDM (par ex., AHP) ; la priorisation en collaboration avec le métier influence la planification et les risques.

Métriques de qualité des exigences (exemples) :

• densité de défauts des exigences (nombre de remarques pour 100 exigences) ;
• nombre de changements après la fixation de la ligne de base ;
• métriques de couverture : part des exigences avec des tests ; part des exigences traçables aux objectifs métier ;
• stabilité des exigences (ratio des exigences ajoutées/supprimées par rapport au nombre total sur une période) ;
• taille/complexité de la spécification (nombre moyen d'exigences par cas d'utilisation, profondeur de la décomposition) ;
• satisfaction des parties prenantes (sondage).

Dans les processus matures (par ex., CMMI niveau 3+), des procédures de qualité des exigences sont en place : vérifications formelles, audits de conformité aux modèles, collecte/analyse de métriques. Dans les domaines critiques (avionique, aérospatial, etc.), des méthodes formelles sont utilisées pour améliorer la fiabilité.

Erreurs typiques

Dans les projets informatiques, les erreurs d'analyse systémique sont fréquentes : exigences incomplètes et ambiguës, contradictions, périmètres flous, ignorance des aspects non fonctionnels, intégration omise et sécurité tardive. Cela conduit à des reprises, des retards, une augmentation des coûts et des défauts.

Problèmes typiques, leurs conséquences et les moyens de les prévenir.

• Incomplétude et exigences omises. Des rôles avec des droits spéciaux, des cas limites et des NFR sont oubliés. Conséquences : refonte de l'architecture et report du lancement. Comment l'éviter : listes de contrôle, brainstormings « et si... », implication précoce des testeurs, traçabilité vers les objectifs métier.

• Formulations vagues et ambiguës. Conséquences : les développeurs réalisent « autre chose », le client est insatisfait. Comment l'éviter : critères mesurables, glossaire, modèles « A, lorsque B, si C », revue par les pairs (peer-review).

• Exigences contradictoires. Conséquences : retards pour clarifications, reprises lors de l'intégration. Comment l'éviter : structuration, vérification des règles métier/réglementations, sessions de résolution de conflits, vérification de la cohérence lors des revues.

• Syndrome du « plaqué or » (gold-plating). Conséquences : augmentation du volume, complexification, nouveaux points de défaillance. Comment l'éviter : lier chaque exigence à un objectif/une métrique ; en Agile, ne pas inclure de superflu dans le backlog ; figer le périmètre (scope) ; voir YAGNI.

• Détail excessif là où il n'est pas nécessaire. Comment l'éviter : séparer le quoi/pourquoi (exigences) du comment (conception/réalisation) ; utiliser des design-free requirements lorsque c'est approprié.

• Manque de gouvernance des exigences. Conséquences : confusion des versions, réalisation de la « mauvaise chose ». Comment l'éviter : une source unique de vérité dans un ALM, historisation et statuts, RTM et analyse d'impact des changements ; gestion des changements via un CCB.

• Absence de participation des utilisateurs. Comment l'éviter : entretiens, observation, prototypes, démonstrations régulières ; validation explicite avec les parties prenantes.

• « Paralysie analytique » excessivement longue. Comment l'éviter : zone de suffisance, itérativité et timeboxing ; lancement de MVP/incréments et ajustement en fonction des retours.

• Ignorance des exigences non fonctionnelles. Comment l'éviter : identifier les NFR (par ex., FURPS+), définir des critères mesurables, les inclure dans le plan de test et les décisions architecturales.

• Erreurs de communication et « facteur humain ». Comment les résoudre : développer les compétences en entretien et en facilitation, rester neutre, documenter les décisions et les sources des exigences (traçabilité vers les objectifs).

La plupart des problèmes se résument à la qualité des formulations, à la complétude et à la gouvernance des exigences ; l'application des normes ISO/IEC/IEEE 29148 et des pratiques du SWEBOK (validabilité, traçabilité, itérativité) réduit considérablement le risque de dépassement des délais et de reprises.

Limites

Malgré son efficacité pour réduire l'incertitude, l'analyse systémique a ses limites :

• La réalité est changeante et complexe. Il est impossible de prendre en compte tous les facteurs, surtout dans les projets à long terme. Certaines exigences apparaîtront inévitablement après le lancement du système. Il est important de chercher à minimiser les surprises, mais il faut être prêt aux changements.
• Les exigences dépendent des gens. Les priorités métier, les lois et le marché peuvent changer. L'analyse systémique fige un état actuel et ne peut pas prédire tous les changements externes. Pour s'adapter, il est nécessaire de mettre à jour régulièrement les exigences et de travailler de manière itérative.
• Les utilisateurs ne savent pas toujours ce qu'ils veulent avant de le voir. C'est une limite bien connue. Le prototypage et les méthodologies agiles, comme Agile, aident à surmonter ce problème. L'analyse sur papier a ses limites, et pour obtenir des données précises, il faut un retour d'expérience sur les réalisations.
• Équilibre entre le temps et la qualité. Une analyse excessivement détaillée peut devenir obsolète. Dans les domaines innovants, il est préférable de créer rapidement un produit minimum viable (MVP) et d'obtenir des données réelles. L'analyse systémique est efficace dans les domaines stables, mais dans les projets de recherche (R&D), son rôle est limité.
• Le facteur humain. Même les meilleures méthodologies ne compensent pas l'incompétence d'un analyste ou l'indisponibilité d'un client. Il est important que tous les participants au processus soient impliqués et motivés.

Influence des technologies modernes sur l'analyse systémique en informatique

L'analyse systémique en informatique évolue constamment sous l'influence des innovations technologiques. L'analyste du XXIe siècle travaille dans un contexte de croissance explosive des données, d'adoption généralisée de l'IA, de cycles de développement rapides et d'une attention accrue à la sécurité. Une pratique réussie de l'analyse systémique exige l'acquisition de nouvelles connaissances (Data Science, cybersécurité, technologies cloud) et de la flexibilité dans l'application des méthodes.

• Données et IA/ML : ce qui est ajouté à l'analyse. Pour les systèmes avec IA, dès le début, on définit les objectifs et le contexte d'application, les exigences relatives aux sources et à la qualité des données, ainsi que les métriques de confiance dans les décisions du modèle (fiabilité, sécurité, explicabilité, confidentialité, équité). On planifie des vérifications TEVV (testing, evaluation, verification, validation), une surveillance en exploitation et un arrêt/retrait sécurisé du modèle. Ces étapes correspondent aux fonctions GOVERN–MAP–MEASURE–MANAGE du cadre NIST sur la gestion des risques de l'IA ; elles sont reflétées dans la SRS, l'architecture et les plans de vérification/exploitation.

• DevSecOps : sécurité « à gauche » et par défaut. L'intégration de la sécurité à chaque étape du CI/CD devient la norme : vérifications automatiques (SAST/DAST), scan des dépendances et des conteneurs, politiques de déploiement, observabilité de base. On utilise des registres d'artefacts de confiance et des images « durcies » standardisées ; les principes du zéro confiance sont appliqués. Dans l'analyse systémique, on décrit à l'avance les points de contrôle du pipeline (conditions pour passer les étapes), le lien entre les exigences et les contrôles de sécurité, et les règles de transition entre les environnements (dev/test/stage/prod).

• Ce qui change dans les documents (artefacts). Quelle section apparaît ou est précisée dans les documents clés en présence de Big Data et d'IA/ML et lors du travail en DevSecOps :
  • SRS / Spécification des exigences : objectifs et contexte d'application de l'IA ; exigences relatives aux données (provenance, qualité, contraintes éthiques et légales) ; métriques du modèle (précision, fiabilité, temps de réponse) ; plan TEVV (testing, evaluation, verification, validation) ; exigences de transparence/explicabilité et de confidentialité ; critères d'arrêt/retrait du modèle de l'exploitation.
  • Architecture et décisions (Architecture, ADR) : résultats de la modélisation des menaces ; mesures de « sécurité par défaut » (chiffrement, contrôle d'accès, gestion des secrets, principe du moindre privilège) ; restrictions sur l'utilisation des données/modèles ; enregistrements ADR avec évaluation des risques et des compromis.
  • Plan de vérification et de validation (V&V / TEVV) : scénarios de test des modèles et des données ; seuils d'acceptation pour les métriques de qualité ; surveillance de la dérive des données/modèles ; procédures de réévaluation périodique et de revalidation.
  • Politiques CI/CD et « portes » du pipeline : vérifications automatiques SAST/DAST, SCA (dépendances), scan des conteneurs ; signature et stockage des artefacts dans des registres de confiance ; règles de promotion entre les environnements (dev/test/stage/prod) et conditions de blocage de la construction en cas d'échec des vérifications ; exigences d'observabilité par défaut.
  • Plan de gestion des données et des modèles : catalogue des sources et lignage (lineage) ; critères de qualité et de disponibilité des données ; versions des datasets/modèles ; calendrier d'(ré)entraînement et contrôle des biais ; politique d'accès et de stockage ; plan de désactivation sécurisée du modèle et de suppression des données si nécessaire.
  • Exploitation et observabilité (Ops/Runbook) : métriques de confiance dans l'IA et SLO ; audit et journalisation ; alertes sur la dégradation/les anomalies ; plan de réponse aux incidents ; fallback/kill-switch pour les composants IA ; exigences de reporting et d'analyse post-incident.
  • Traçabilité (end-to-end) : liens explicites « exigence ↔ contrôle/vérification dans le pipeline » et « exigence ↔ test/surveillance en exploitation », afin de pouvoir vérifier de manière prouvable la sécurité et la qualité tout au long du cycle de vie.
• Rôle de l'analyste système.
  • gère le contexte et les risques de l'IA (acteurs, scénarios d'application, hypothèses et limites des données) ;
  • assure la traçabilité « exigence ↔ contrôle de sécurité dans le pipeline » ;
  • formule des exigences non fonctionnelles vérifiables (sécurité, transparence, observabilité) tout au long du cycle de vie du système.

Différences avec l'analyse systémique classique

Le terme « analyse systémique » est historiquement plus large que le développement de logiciels. L'analyse systémique classique est une approche pour résoudre des problèmes complexes et interdisciplinaires (sociaux, économiques, managériaux), basée sur la pensée systémique et des méthodes quantitatives, généralement pour soutenir les décisions de gestion. En informatique, l'analyse systémique est comprise comme une discipline appliquée dans le domaine de l'ingénierie logicielle, axée sur la création de systèmes d'information.

Voici les principales différences.

• Objectifs et objet de l'analyse. L'analyse classique résout des problèmes mal structurés et « flous » et améliore des systèmes sociotechniques existants (réseau de transport urbain, stratégie d'entreprise, politique environnementale). L'objet est un système réel ; la tâche est d'aider le décideur à choisir une ligne de conduite. Pour l'analyse systémique en informatique, l'objectif est de concevoir et de créer un nouveau système d'information ou produit logiciel répondant aux exigences. L'objet est le système en cours de conception ; l'accent est mis sur le comportement et les caractéristiques nécessaires aux utilisateurs.

• Fondements méthodologiques. Les écoles classiques s'appuient sur la pensée systémique et souvent sur les mathématiques. L'approche dure (hard systems) implique la formalisation du problème, des critères quantitatifs, l'optimisation (comme en recherche opérationnelle). Les méthodologies douces (soft systems) reconnaissent la multiplicité des points de vue ; un exemple est la Soft Systems Methodology (SSM), où, par le biais de discussions et de modèles conceptuels, on s'accorde sur les changements souhaités. En informatique, la base est constituée de disciplines d'ingénierie : ingénierie des exigences, conception de logiciels, cadres architecturaux. On applique des processus standardisés (ISO/IEC/IEEE 15288, 12207, 29148), des notations UML/SysML et des pratiques de gestion du changement.

• Rôles et artefacts. Dans l'analyse classique, le rôle de « l'analyste système » est souvent informel ; les résultats sont un rapport d'analyse, des recommandations, des modèles mathématiques, des scénarios « et si ». En informatique, le rôle de l'analyste (ou de l'analyste métier) est formalisé ; des spécifications d'exigences, des modèles de système (UML, ER), des spécifications d'interfaces, des user stories et un backlog sont produits — des artefacts directement utilisés par les développeurs et les testeurs.

• Cycle de vie et processus. L'analyse classique n'a pas de modèle unique : les étapes dépendent du problème (dans la SSM, de l'étude de la situation à la mise en œuvre des changements). En informatique, des cycles SDLC standard sont adoptés : dans le modèle en cascade, il y a une phase distincte d'analyse des exigences ; dans les approches itératives et agiles, l'analyse est une activité constante à chaque sprint. Les pratiques modernes (DevOps, CI/CD) étendent le cadre de l'analyse à l'exploitation : les exigences de maintenance, d'observabilité et de mise à jour sont prises en compte. Autrement dit, l'analyse systémique en informatique est intégrée au cycle de vie du développement, tandis que l'analyse classique est plus souvent menée comme une activité de projet/conseil.

L'analyste système

L'analyste système en informatique est un spécialiste responsable de la pensée systémique dans la conception et le développement de systèmes d'information : formulation et validation des exigences, modélisation (UML/BPMN), alignement des décisions architecturales et garantie de l'intégration. Le rôle et les exigences de qualification en FR sont définis dans des normes professionnelles et des référentiels de formation.

Objectif principal du type d'activité professionnelle : Assurer la conformité du service informatique, du système automatisé, du système d'information automatisé, du système de gestion automatisé, du produit ou de l'outil logiciel ou d'information (ci-après dénommé le Système) avec son environnement, les exigences et contraintes initiales, les objectifs d'automatisation et l'activité automatisée, en élaborant et en transmettant des solutions de conception de qualité et interdépendantes aux parties prenantes lors du lancement et de la coordination des travaux des exécutants individuels tout au long du cycle de vie du Système (Norme professionnelle « Analyste système » (arrêté du ministère du Travail de la Fédération de Russie du 27.04.2023 n° 367n).

Glossaire des termes clés

Concepts de base et acteurs

• Analyse systémique en informatique — discipline dont l'objet est le système d'information tout au long de son cycle de vie, de la conception à l'exploitation.
• Parties prenantes (Stakeholders) — individus ou groupes intéressés par le projet ou affectés par celui-ci (clients, utilisateurs, managers).
• Artefacts de projet — documents et résultats créés au cours d'un projet, tels que les spécifications, les modèles, les plans et les décisions.

Exigences : types et documentation

• Exigences fonctionnelles — décrivent ce que le système doit faire ; ses fonctions et son comportement.
• Exigences non fonctionnelles — décrivent les attributs de qualité du système (fiabilité, performance, sécurité, facilité d'utilisation, scalabilité, etc.).
• Spécification des exigences (primaire) — document contenant l'ensemble initial des exigences recueillies lors des premières étapes du projet.
• SRS (Software Requirements Specification) — document standardisé décrivant en détail les exigences logicielles selon les normes internationales (par exemple, ISO/IEC/IEEE 29148).
• URS (User Requirements Specification) — document décrivant les exigences de l'utilisateur vis-à-vis du système du point de vue des processus métier et des attentes de l'utilisateur final.

• Exigences architecturalement significatives (ASR) — exigences ayant une influence substantielle sur les décisions et les compromis architecturaux.
• Exigences transversales (CFR) — synonyme d'exigences non fonctionnelles, soulignant leur nature transversale.
• Critères d'acceptation (Acceptance Criteria) — conditions vérifiables qui, une fois remplies, valident que le travail sur une exigence est accepté.
• Definition of Ready (DoR) — accord sur l'état de préparation d'un élément du backlog pour le développement (clarté, estimation, critères).
• Definition of Done (DoD) — accord sur l'état « terminé » d'un travail (code, tests, documentation, déploiement).
• Contrainte (Constraint) — condition stricte qui limite les solutions (délais, plateformes, normes, licences).
• Hypothèse (Assumption) — supposition acceptée sans preuve, nécessitant une validation ultérieure.
• Qualité des exigences — propriétés selon ISO 29148 : non-ambiguïté, complétude, cohérence, vérifiabilité, atomicité.

Formalisation, traçabilité et priorisation des exigences

• Formalisation des exigences — processus de transformation des demandes informelles en exigences claires, vérifiables et non ambiguës.
• Traçabilité des exigences — capacité à suivre le cycle de vie d'une exigence depuis sa source jusqu'à sa mise en œuvre, ses tests et son déploiement.
• Traçabilité bidirectionnelle (Bidirectional traceability) — capacité à suivre les liens entre les exigences, les éléments de conception et les scénarios de test dans les deux sens.
• MoSCoW — technique de priorisation des exigences qui les classe en Must-have (doit avoir), Should-have (devrait avoir), Could-have (pourrait avoir) et Won't-have (n'aura pas).
• BDD (Behavior-Driven Development) — méthodologie de développement où les tests sont écrits en langage naturel, axé sur le comportement du système du point de vue de l'utilisateur (format Given–When–Then).

Notations et modélisation

• UML (Unified Modeling Language) — langage de modélisation graphique standardisé pour la spécification, la visualisation, la construction et la documentation des composants des systèmes logiciels.
• SysML (Systems Modeling Language) — extension de l'UML pour l'ingénierie système, prenant en charge la modélisation de divers aspects des systèmes complexes, y compris les exigences, le comportement, la structure et les paramètres.
• BPMN (Business Process Model and Notation) — norme de notation graphique pour la description des processus métier, permettant de visualiser les flux de travail, les événements, les passerelles et les pools.
• MBSE (Model-Based Systems Engineering) — approche de l'ingénierie système où le modèle est l'artefact central à toutes les étapes du cycle de vie du système, des exigences aux tests.
• ArchiMate — notation pour l'architecture d'entreprise (métier, applications, technologies) et leurs relations.
• DMN (Decision Model and Notation) — modélisation des décisions métier et des tables de règles.
• DFD (Data Flow Diagram) — diagrammes de flux de données (contexte, niveaux de décomposition).
• ERD (Entity-Relationship Diagram) — modèle du domaine avec des entités, des relations et des attributs.
• Matrice CRUD — correspondance entre les opérations Create/Read/Update/Delete, les entités et les rôles/fonctions.

Styles architecturaux et évaluation des solutions

• Architecture monolithique — approche architecturale où l'ensemble du système est développé comme un module unique et indivisible.
• Architecture microservices — approche architecturale où le système est construit comme un ensemble de petits services, déployables et évolutifs de manière indépendante.
• Compromis (Trade-off) — choix entre des caractéristiques ou des solutions mutuellement exclusives ou contradictoires, où l'amélioration d'une caractéristique se fait au détriment d'une autre.
• ATAM (Architecture Tradeoff Analysis Method) — méthode d'évaluation de l'architecture logicielle utilisée pour analyser les compromis entre les attributs de qualité (par exemple, la performance, la scalabilité).

Architecture d'entreprise et cadres de référence

• TOGAF (The Open Group Architecture Framework) — l'un des cadres d'architecture d'entreprise les plus répandus, incluant la méthode ADM (Architecture Development Method) pour développer et gérer l'architecture.
• Zachman Framework — ontologie des artefacts de l'architecture d'entreprise, présentée sous la forme d'une matrice 6×6, classifiant divers aspects de l'architecture sous différentes perspectives.

Approches d'analyse et processus de développement

• Approche dure (Hard Systems) — méthodologie d'analyse systémique supposant des objectifs et des exigences formalisables à l'avance, une décomposition et une conception « de haut en bas », efficace pour les tâches clairement définies.
• Approche douce (Soft Systems) — méthodologie d'analyse systémique utilisée lorsque les objectifs sont flous et que les points de vue des parties prenantes sont multiples, visant à aligner la compréhension du problème et les changements souhaités.
• SSM (Soft Systems Methodology) — méthodologie spécifique de l'approche systémique douce, développée par Peter Checkland, utilisant des outils tels que la rich picture, les définitions racines et CATWOE.
• Modèle en cascade (Waterfall) — méthodologie classique de développement logiciel où les étapes (analyse, conception, mise en œuvre, test, déploiement) sont exécutées séquentiellement, chaque étape étant entièrement terminée avant le début de la suivante.
• Agile — groupe de méthodologies de développement logiciel flexibles, axées sur le développement itératif, l'adaptation aux changements, l'interaction avec le client et la livraison continue de valeur.

Méthodes de choix et erreurs typiques

• AHP (Analytic Hierarchy Process) — méthode de choix multicritères permettant de structurer des problèmes complexes et d'évaluer des alternatives sur la base d'une hiérarchie de critères.
• Gold-plating (syndrome du « plaqué or ») — erreur en analyse systémique consistant à ajouter des fonctionnalités non requises par les parties prenantes, ce qui entraîne une augmentation du volume et de la complexité du projet.

Liens

• ISO/IEC/IEEE 15288:2023 — System life cycle processes
• ISO/IEC/IEEE 12207:2017 — Software life cycle processes
• ISO/IEC/IEEE 29148:2018 — Requirements engineering
• ISO/IEC/IEEE 42010:2022 — Architecture description
• ISO/IEC 25010:2023 — Product quality model (SQuaRE)
• ISO/IEC/IEEE 24748-2:2024 — Life cycle management — Guidelines for applying ISO/IEC/IEEE 15288
• ISO/IEC/IEEE 15289:2019 — Content of life-cycle information items (documentation)
• ISO/IEC/IEEE 42020:2019 — Architecture processes
• ISO/IEC/IEEE 29119-1:2022 — Software testing — Part 1: General concepts
• IEEE Std 1012-2024 — System, Software, and Hardware Verification and Validation

• UML 2.5.1 — OMG Specification
• BPMN 2.0.2 — OMG Specification
• SysML v1.7 — OMG Specification

• TOGAF Standard, 10th Edition — The Open Group
• ArchiMate 3.2 — The Open Group

• SEI ATAM — Architecture Tradeoff Analysis Method
• NASA Systems Engineering Handbook, SP-2016-6105 Rev2 (PDF)

• SWEBOK Guide v4.0a — IEEE Computer Society (PDF)
• Guide to the Systems Engineering Body of Knowledge (SEBoK)

• BABOK Guide v3 — IIBA
• Google SRE Books — Official site
• Microsoft Azure Well-Architected Framework — Official docs
• Системный анализ простыми словами. YouTube
• Системный анализ в IT простыми словами. YouTube

Bibliographie

• ISO/IEC/IEEE (2023). 15288: System Life Cycle Processes.
• INCOSE (2023). INCOSE Systems Engineering Handbook, 5e éd.
• ISO/IEC/IEEE (2018). 29148: Systems and Software Engineering — Life Cycle Processes — Requirements Engineering.
• IIBA (2015). A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), v3.
• The Open Group (2022). The TOGAF® Standard, 10th Edition. Version officielle gratuite.
• OMG (2017). Unified Modeling Language (UML®) 2.5.1 Specification. PDF.
• OMG (2014). Business Process Model and Notation (BPMN™) 2.0.2 Specification. PDF.
• OMG (2024). Systems Modeling Language (SysML®) 1.7 Specification. PDF.
• The Open Group (2022). ArchiMate® 3.2 Specification. Téléchargement officiel gratuit (sous licence).
• Bass, L.; Clements, P.; Kazman, R. (2021). Software Architecture in Practice, 4e éd.
• Wiegers, K.; Beatty, J. (2013). Software Requirements, 3e éd.
• Rozanski, N.; Woods, E. (2012). Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, 2e éd.
• Meadows, D. (2008). Thinking in Systems: A Primer.
• Senge, P. M. (2006). The Fifth Discipline: The Art & Practice of the Learning Organization (éd. révisée).
• Blanchard, B. S.; Fabrycky, W. J. (2010). Systems Engineering and Analysis, 5e éd.
• Robertson, J.; Robertson, S. (2012). Mastering the Requirements Process: Getting Requirements Right, 3e éd.
• van Lamsweerde, A. (2009). Requirements Engineering: From System Goals to UML Models to Software Specifications.
• Hull, E.; Jackson, K.; Dick, J. (2017). Requirements Engineering, 4e éd.
• Kendall, K. E.; Kendall, J. E. (2023). Systems Analysis and Design, 11e éd.
• Dennis, A.; Wixom, B. H.; Tegarden, D. (2021). Systems Analysis and Design: An Object-Oriented Approach with UML, 8e éd.
• Satzinger, J. W.; Jackson, R. B.; Burd, S. D. (2015). Systems Analysis and Design in a Changing World, 7e éd.
• Fowler, M. (2003). UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3e éd.
• Delligatti, L. (2013). SysML Distilled: A Brief Guide to the Systems Modeling Language.
• Silver, B. (2011). BPMN Method and Style, 2e éd.
• Lankhorst, M. et al. (2017). Enterprise Architecture at Work: Modelling, Communication and Analysis, 4e éd.
• Richards, M.; Ford, N. (2020). Fundamentals of Software Architecture.
• Fairbanks, G. (2010). Just Enough Software Architecture: A Risk-Driven Approach.
• Keeling, M. (2017). Design It!: From Programmer to Software Architect.
• Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software.
• Vernon, V. (2013). Implementing Domain-Driven Design.
• Brandolini, A. (2018). Introducing EventStorming: An Act of Deliberate Collective Learning.
• Simsion, G.; Witt, G. (2015). Data Modeling Essentials, 4e éd.
• Silverston, L. (2008–2009). The Data Model Resource Book, Vols. 1–3 (éd. révisées).
• Keeney, R. L.; Raiffa, H. (1993). Decisions with Multiple Objectives: Preferences and Value Trade-Offs, 2e éd.
• Saaty, T. L. (1980). The Analytic Hierarchy Process; (1990) Decision Making for Leaders.

Notes

Category:Computer science