Conception de la solution · Étape 03 · Comment nous travaillons
La stratégie et l'architecture définissent comment un système devrait être structuré. La conception de la solution détermine exactement ce qui doit être construit — les flux de travail spécifiques, les interfaces, les contrats de données et les comportements en cas de défaillance qui transforment une orientation d'ingénierie en quelque chose qu'une équipe peut effectivement construire.
Cette étape ne commence pas par une implémentation. Elle commence par une spécification qui a été testée sur la base de preuves avant qu'une seule ligne de code de production ne soit écrite.
Pas cette question
"Que devons-nous construire ?"
Cette question, plutôt
"Cette conception spécifique se comporte-t-elle réellement comme nous l'attendons, dans les conditions auxquelles elle sera réellement confrontée — et pouvons-nous le prouver avant d'engager des efforts d'ingénierie pour la construire ?"
Concevoir · Prototyper · Tester · Mesurer · Spécifier
Pourquoi la conception suit l'architecture
L'architecture de référence de l'étape précédente définit les couches, les choix technologiques et les préoccupations transversales. Elle ne définit pas encore comment un flux de travail spécifique doit se comporter lorsqu'une demande est ambiguë, ni ce qui se passe lorsqu'une intégration renvoie des données malformées. La conception de la solution comble cette lacune — sans elle, "architecture" reste un diagramme, pas un système.
Architecture de référence → Spécification de la solution
Pourquoi la rigueur de conception compte
Les recherches de Barry Boehm sur l'économie du génie logiciel — publiées pour la première fois en 1976 et développées dans son livre de 1981 Software Engineering Economics — ont montré que le coût de correction d'un défaut augmente considérablement plus la découverte est tardive.
~1×
Coût de la correction d'un défaut détecté pendant la conception.
Boehm, Software Engineering Economics (1981); Boehm & Basili, IEEE Computer (2001).
10×–100×
Coût de la correction du même défaut après la mise en production, en fonction de l'échelle du projet.
Boehm, Software Engineering Economics (1981); Boehm & Basili, IEEE Computer (2001).
Cette conclusion a été réexaminée depuis. La révision de Boehm et Basili en 2001 a montré que la courbe est sensiblement plus plate pour les petites équipes itérant rapidement disposant de tests solides et d'une livraison continue. Le multiplicateur n'est pas universel, et nous ne le traitons pas comme tel.
Mais le sens de la conclusion n'a pas été infirmé : détecter une erreur de conception avant sa construction est moins coûteux que de la détecter après. C'est pourquoi OpenQCore considère le prototypage et les tests comme faisant partie intégrante de la conception — et non comme une phase qui intervient une fois le développement déjà lancé.
De l'architecture à la spécification
Chaque décision architecturale de l'étape précédente est décomposée en spécifications concrètes.
La séquence exacte des étapes, des points de décision, des exceptions et des transferts que la solution doit prendre en charge — fondée sur le modèle de flux de travail à l'état actuel produit lors de la découverte, et non sur un processus idéal réinventé.
Ce que chaque utilisateur, système ou agent voit, envoie et reçoit réellement — écrans, flux conversationnels, contrats d'API et les champs pertinents à chaque étape.
La forme exacte, les règles de validation, la stratégie de versionnage et la propriété des données circulant entre les composants.
Ce que le système fait — et ce qu'il ne fait explicitement pas — en conditions normales, dans les cas limites et en cas de défaillance.
Résultat
Spécification de la solution (brouillon)
Conception du flux de travail et des interactions
Une interface conversationnelle superposée à un flux de travail défaillant ne répare pas le flux de travail — elle le masque, jusqu'à ce que la contrainte sous-jacente réapparaisse ailleurs.
La conception de la solution part des éléments probants du flux de travail recueillis lors de la phase de découverte, et pose une question structurelle avant la question d'interface : quelles étapes de ce processus doivent être automatisées, lesquelles doivent rester humaines, et où la responsabilité est-elle exactement transférée entre elles ? Nous cartographions cela explicitement, afin que les points d'intervention humaine soient une décision de conception délibérée — et non le résultat accidentel des capacités technologiques.
Points de contrôle explicites où la révision, le jugement ou l'autorisation humaine sont nécessaires par conception — pas par omission.
Limites précisément définies sur ce qu'un système est autorisé à décider ou à exécuter sans validation humaine.
Parcours conçus pour les cas qui échappent au traitement normal — pas des échecs silencieux ni des mécanismes de repli par défaut.
Prototypage et expérimentation
OpenQCore considère la conception en phase initiale de la même manière que la science du design considère un artefact des systèmes d'information : comme quelque chose construit spécifiquement pour pouvoir être évalué face à un problème réel, et non simplement admiré pour son élégance. Cette approche — formalisée dans l'influent Design Science in Information Systems Research de Hevner et al. (MIS Quarterly, 2004) — considère l'artefact et son évaluation comme indissociables. Nous appliquons le même raisonnement guidé par l'hypothèse utilisé lors de la découverte, au niveau de la conception.
Une décision de conception spécifique et falsifiable — pas une orientation vague.
Une représentation fonctionnelle suffisante pour tester la décision — pas forcément prête pour la production.
Des entrées réelles ou représentatives de façon réaliste, pas des exemples idéalisés choisis pour réussir.
Comparaison avec la ligne de base et les critères de réussite établis lors de la phase de découverte — pas une impression subjective de qualité.
La conception est conservée, modifiée ou abandonnée en fonction des résultats du test — pas en fonction du travail déjà investi.
L'objectif d'un prototype n'est pas de démontrer qu'une conception peut fonctionner. Il est de déterminer si elle fonctionne de manière fiable, dans les conditions auxquelles le système final sera réellement confronté.
Spécification des données et des interfaces
Les échecs d'intégration n'ont que rarement pour origine une décision manifestement erronée. Ils proviennent plutôt de l'ambiguïté — un champ supposé toujours présent, un cas d'erreur que personne n'a consigné, une incompatibilité de versions que personne n'avait prévue.
C'est un travail délibérément peu glamour. C'est aussi le travail qui détermine si un système qui fonctionne bien lors d'une démonstration continue de bien fonctionner en production, après six intégrations et dix-huit mois.
Concevoir pour les défaillances, pas seulement pour le succès
La plupart des échecs de conception ne concernent pas le chemin heureux. Ils concernent ce qui se passe quand quelque chose tourne mal — un système en amont dépasse son délai, un document ne s'extrait pas correctement, un modèle est incertain, un utilisateur fait quelque chose d'inattendu. OpenQCore conçoit ces conditions délibérément plutôt que de les découvrir en production.
Ce que fait le système lorsque la confiance dans une sortie est faible — y compris s'il le signale et comment il le fait.
Quelles fonctions restent disponibles lorsqu'une dépendance échoue, plutôt qu'une panne totale du système.
Les conditions spécifiques dans lesquelles un cas est transféré à un humain, et quel contexte accompagne ce transfert.
Comment le système se comporte face à des entrées malformées, des séquences inattendues ou des tentatives d'utilisation abusive — pas seulement des requêtes bien formées.
Un système à qui l'on n'a jamais demandé « que se passe-t-il en cas de défaillance ? » n'a pas vraiment été conçu. Il a seulement été démontré.
Critères de validation définis avant le développement
Conformément au principe établi lors de la phase de découverte — selon lequel le succès doit être défini avant la mise en œuvre — la conception de la solution produit des critères d'acceptation explicites et écrits ainsi qu'un plan de test avant le début du développement en production.
Ce que la solution doit accomplir correctement, formulé en termes testables.
Conformes aux caractéristiques de qualité logicielle reconnues — y compris l'efficacité des performances, la fiabilité, l'utilisabilité, la sécurité et la maintenabilité, telles qu'organisées par le modèle de qualité des produits logiciels ISO/IEC 25010 — spécifiés comme des objectifs mesurables plutôt que comme des aspirations générales.
Les scénarios, ensembles de données et conditions spécifiques contre lesquels la solution sera évaluée avant d'être considérée prête à être développée en production.
La phase de revue de conception
Cette pratique a un précédent : la méthode formelle d'inspection de la conception et du code de Michael Fagan, introduite chez IBM en 1976, a établi qu'une revue structurée basée sur des critères détecte les défauts plus tôt et de manière plus fiable qu'une approbation informelle. OpenQCore applique le même principe à la conception de la solution.
La spécification est suffisamment précise, le prototype a satisfait à ses critères d'évaluation, et le développement peut commencer.
L'orientation principale est solide, mais des éléments spécifiques nécessitent une révision en fonction de ce que les tests ont révélé.
Le travail de conception a révélé une contrainte que l'architecture n'avait pas prise en compte — la réponse appropriée est de revoir la structure, plutôt que de concevoir en la contournant.
Le travail de conception a révélé un risque — technique, opérationnel, de sécurité ou éthique — qui nécessite une décision dépassant l'autorité de l'équipe de conception avant de poursuivre.
Un garde-fou de conception qui accepte toujours n'en est pas un.
Ce que produit la conception de la solution
Selon la portée de l'engagement, cette étape produit :
Flux de travail, interfaces, contrats de données et comportements, avec suffisamment de détails pour permettre la construction sans devoir redéfinir l'intention.
Représentations visuelles du flux de processus, incluant les points explicites d'intervention humaine.
Schémas, règles de validation et stratégie de gestion des versions pour chaque interface entre composants.
Ce qui a été testé, par rapport à quelle référence, et ce que les résultats confirment ou excluent.
Conditions de défaillance documentées et la réponse prévue du système à chacune.
Conditions spécifiques et mesurables que la solution construite doit satisfaire avant le déploiement.
De la conception au développement et à l'intégration
La conception de la solution produit une spécification testée et validée — pas un système achevé. L'étape suivante transforme cette spécification en logiciel opérationnel, intégré aux systèmes avec lesquels il doit fonctionner.
Spécification de la solution → Évaluation du prototype → Critères d'acceptation → Développement et intégration
Étape 04
Construire la solution spécifiée selon les critères d'acceptation définis — pas selon des hypothèses.
Références de recherche et méthodologiques
Boehm, B. — Software Engineering Economics (1981) ; Boehm, B. & Basili, V. — « Software Defect Reduction Top 10 List », IEEE Computer (2001)
Source des conclusions sur le coût du changement mentionnées ci‑dessus, y compris la révision ultérieure montrant une courbe plus plate pour les équipes plus petites et à itération rapide.
Hevner, A., March, S., Park, J., & Ram, S. — « Design Science in Information Systems Research », MIS Quarterly (2004)
Cadre fondamental pour considérer un artefact de système d'information et son évaluation comme indissociables — la base du cycle prototyper-tester-affiner décrit ci‑dessus.
Fagan, M. — « Design and Code Inspections to Reduce Errors in Program Development », IBM Systems Journal (1976)
Origine de la revue de conception structurée, fondée sur des critères, en tant que pratique d'ingénierie formelle, mentionnée dans la « Design Review Gate » ci‑dessus.
ISO/IEC 25010:2011 — Exigences et évaluation de la qualité des systèmes et logiciels (SQuaRE) — Modèles de qualité des systèmes et logiciels
Source des caractéristiques de qualité non fonctionnelles mentionnées dans les critères d'acceptation ci‑dessus.
