SyncThinkDesignSTD

Fondements · v0.2

Des processus synchronisés, des systèmes qui évoluent

La proposition originale de SyncThinkDesign, avec son vocabulaire et sa portée. Le reste du site est subordonné à cette page.

Comment lire cette page

On trouve ici les principes (F) de SyncThinkDesign : ils expriment la proposition et ne se démontrent pas ; on les adopte, on les discute ou on les rejette. Les aspirations (A) sont ce que la proposition veut devenir. Les outils pour l’appliquer et les hypothèses sur ses effets se trouvent dans la formalisation ; son implémentation technologique, dans AAA3. Aucune de ces deux couches ne redéfinit ce qui est dit ici.

L’idée centrale

SyncThinkDesign propose de comprendre la création de systèmes comme l’évolution d’un système par des processus synchronisés, interdépendants et nourris en continu les uns par les autres.

Le mot système est délibérément large : ce peut être un logiciel, un service, une organisation, un cours, une œuvre ou un écosystème d’outils. Ce qui importe, c’est qu’il est conçu, construit et utilisé, et que ces trois choses n’arrivent pas une seule fois et dans l’ordre, mais se superposent tout au long de sa vie.

Les quatre processus

F1Principe

Capter (Sync), Concevoir (Think), Exécuter (Design) et Optimiser (Refine) sont des processus capables de fonctionner en parallèle, de s’influencer mutuellement et de modifier l’évolution d’un système pendant qu’il est conçu, construit ou utilisé.

Les quatre processus tels que les formule la proposition originale.
ProcessusCe qu’il est dans SyncThinkDesignCe qui change par rapport à une séquence
Capter (Sync)Collecte continue de données, de signaux et de contexte tout au long de la vie du système.Elle n’a pas lieu seulement au début : elle informe les autres processus pendant que le système évolue.
Concevoir (Think)Génération d’idées qui se déroule en parallèle de la captation, de l’exécution et de l’optimisation.Les idées n’attendent pas la fin d’un cycle pour être validées ; elles sont mises à l’épreuve à mesure qu’elles émergent.
Exécuter (Design)Construction qui évolue avec chaque nouvelle captation et chaque nouvelle idée.On n’attend pas d’avoir une conception complète pour commencer : exécuter fait partie de la conception.
Optimiser (Refine)Amélioration continue qui accompagne les autres processus.Ce n’est pas une phase ultérieure : chaque partie s’améliore pendant qu’elle évolue.
  1. CapterSync↓ Concevoir: données et contexte
    ↑ Concevoir: quoi observer
  2. ConcevoirThink↓ Exécuter: idées et décisions
    ↑ Exécuter: découvertes
  3. ExécuterDesign↓ Optimiser: le système en usage
    ↑ Optimiser: améliorations
  4. OptimiserRefine↓ Capter: nouvelles questions
    ↑ Capter: signaux
  5. Système en évolution
Système en évolutionCapter → Concevoir: données et contexte. Concevoir → Capter: quoi observer. Concevoir → Exécuter: idées et décisions. Exécuter → Concevoir: découvertes. Exécuter → Optimiser: le système en usage. Optimiser → Exécuter: améliorations. Optimiser → Capter: nouvelles questions. Capter → Optimiser: signauxSystème en évolutiondonnées et contextequoi observeridées et décisionsdécouvertesle système en usageaméliorationsnouvelles questionssignauxCapterSyncConcevoirThinkExécuterDesignOptimiserRefine
Figure 1. Les quatre processus s’influençant mutuellement sur un même système en évolution. Les étiquettes sont des exemples de ce qui peut circuler entre eux, pas une liste fermée ni un ordre obligatoire.

Synchronisation

F2Principe

La synchronisation plutôt que la séquence. L’information produite par un processus peut agir sur les autres sans attendre la clôture d’une phase. Synchroniser n’exige ni simultanéité littérale ni latence nulle : le temps de réponse dépend de la nature du système.

C’est le principe dont découlent les autres. Il ne dit pas comment l’information doit circuler — une conversation, un tableau, un document, le système lui-même en usage — mais qu’elle ne doit pas rester retenue en attendant la fin d’une étape. Les manières d’y parvenir sont nombreuses, et la formalisation en décrit quelques-unes sans prétendre les épuiser.

Évolution organique et continue

F3Principe

L’évolution organique et continue plutôt que les séquences rigides. Un système peut changer d’objectifs, de structure, de composants et de comportement sous l’effet de l’interaction continue entre ses processus.

Évolution et itération ne sont pas incompatibles. Une évolution continue peut contenir des milliers de petites itérations, ainsi que des revues, des livraisons et des versions. Ce que SyncThinkDesign remet en question, c’est que le système doive attendre d’avoir achevé une phase ou un cycle entier pour intégrer une information pertinente. Aucune cadence fixe ne définit la méthode.

F4Principe

L’émergence plutôt que la planification exhaustive. Les solutions peuvent naître de l’interaction entre processus synchronisés et pas seulement d’un plan défini à l’avance. Planifier reste utile ; ce qui est remis en question, c’est la prétention que le plan détermine tout.

F5Principe

Des systèmes adaptatifs plutôt que des produits figés. Chaque projet peut être compris comme un système qui s’adapte à son environnement et continue de changer, plutôt que comme un artefact achevé. La comparaison avec les systèmes vivants est une analogie conceptuelle : elle aide à regarder, elle ne prétend pas expliquer.

Valider, optimiser et capter sans pause

F6Principe

La validation continue plutôt que la vérification finale. Les idées et les décisions sont mises à l’épreuve pendant que le système évolue, et pas seulement à la fin d’un cycle.

F7Principe

Une optimisation intégrée à l’évolution. Améliorer n’est pas une phase qui vient après la création. Chaque partie du système peut être optimisée pendant qu’elle évolue.

F8Principe

Une captation permanente de l’information. L’observation du système, de ceux qui l’utilisent et de son contexte accompagne toute sa vie, et nourrit les autres processus au moment même où elle a lieu.

Personnes et organisation

F9Principe

Le décloisonnement des fonctions. Si la recherche, la conception, le développement et l’amélioration vivent dans des équipes ou des moments isolés, la synchronisation devient impossible. Les processus ont besoin de canaux par lesquels s’influencer.

F10Principe

Un état d’esprit synchrone. Appliquer SyncThinkDesign demande une disposition avant un outil : accepter que ce qui se construit aujourd’hui puisse changer à cause de ce qu’on observera demain, et organiser le travail pour que ce soit possible.

F11Principe

La complexité et l’incertitude comme sources possibles d’innovation. Ce qui ne peut être prévu n’est pas seulement un risque à gérer ; ce peut aussi être l’origine de solutions qu’aucun plan n’aurait contenues.

Le design comme évolution

F12Principe

Le design, c’est aussi la manière dont une chose évolue. Concevoir un système, c’est aussi décider ce qui peut y changer, quelle information le fait changer et qui peut intervenir dans ce changement.

Ce que SyncThinkDesign n’exige pas

  • Que les quatre processus travaillent littéralement en même temps, ni qu’ils répondent en un temps nul.
  • Un outil, un format ou un registre particulier.
  • Que chaque décision créative, organisationnelle ou technique soit formulée comme une hypothèse réfutable.
  • Renoncer à planifier, à itérer ou à publier des versions.
  • Que tout change à la fois : une partie du système peut rester stable pendant que les autres continuent d’évoluer.

Portée

SyncThinkDesign ne se limite pas au logiciel, aux intégrations ni aux projets qui utilisent l’intelligence artificielle. La proposition originale parle d’écosystèmes, et nous les conservons comme terrains où l’examiner. Nous n’affirmons pas qu’elle fonctionne mieux dans tous : nous les présentons comme une proposition ouverte à l’expérimentation.

Écosystèmes de la proposition originale et autres domaines où elle pourrait être examinée. Les exemples sont illustratifs, pas des cas documentés.
ÉcosystèmeCe qui évolueÀ quoi pourrait ressembler la synchronisation
TechnologiquesLogiciels, plateformes, intégrations entre systèmes.L’usage réel modifie ce qui est en construction, sans attendre la prochaine version majeure.
D’expérienceInterfaces, services, expériences interactives.Ce qu’on observe chez ceux qui utilisent quelque chose en modifie le design pendant qu’il reste en usage.
OrganisationnelsProcessus, structures, modes de coordination.Ce qu’apprend une activité modifie la décision d’un autre service sans passer par un cycle annuel.
CréatifsŒuvres, musique, design, production audiovisuelle.Ce qui apparaît en exécutant une pièce change l’idée de la pièce.
ÉducatifsCours, programmes, supports.Ce qu’on observe chez ceux qui apprennent modifie le cours pendant qu’il se déroule.
Stratégiques et de servicesStratégies, modèles de service.Des signaux de l’environnement modifient la stratégie sans attendre la prochaine planification.
A1Aspiration

Que SyncThinkDesign puisse être examinée dans des contextes technologiques, organisationnels, créatifs, éducatifs, stratégiques et de conception de services, et que ces examens disent aussi où elle n’est d’aucune aide.

Ce qu’on attend de son application

La proposition originale soutient que synchroniser les processus réduit les délais, accroît la capacité d’adaptation, fait émerger la qualité de la validation continue et accélère l’apparition de solutions nouvelles. Nous conservons ces attentes, mais pas comme des faits : ce sont les hypothèses H1, H2, H3 et H4 de la formalisation, et elles ont besoin de preuves.

Liens avec d’autres approches

SyncThinkDesign ne remplace pas d’autres cadres de travail : elle cherche à s’intégrer à eux et à apporter la synchronisation entre des processus qu’ils traitent souvent séparément. Le tableau résume, aussi honnêtement que possible, ce qu’elle reconnaît à chacun et comment elle s’y rattache.

La colonne de droite décrit la relation que propose STD ; ce ne sont pas des résultats vérifiés.
ApprocheCe que STD reconnaîtComment elle s’y rattache
Ingénierie concouranteSuperposer des phases auparavant séquentielles pour détecter les problèmes plus tôt. C’est l’antécédent le plus direct.Elle partage la superposition. STD met l’accent sur l’évolution du système et sur l’émergence, et la transpose hors de l’industrie manufacturière.
Agile / ScrumItérations courtes, adaptabilité, livraisons incrémentales.Les sprints peuvent vivre à l’intérieur de STD ; ce que STD ajoute, c’est la synchronisation continue entre les quatre processus, y compris au sein d’un sprint.
Design ThinkingCentré sur les personnes, empathie, idéation créative, prototypes.STD partage la co-création, mais ne sépare ni la recherche de la construction, ni l’idéation de la validation.
Lean StartupValidation d’hypothèses, produits minimaux, pivots.C’est le parent le plus proche. STD propose que capter, concevoir, construire et mesurer se déroulent en même temps sur différentes parties du système, et pas seulement en tours successifs d’une boucle.
DevOpsIntégration continue, automatisation, supervision.Elle partage le couplage entre construire et exploiter ; STD l’étend à l’idéation et à l’observation qui précèdent le code.
Conception centrée sur l’humainAttention aux besoins humains, recherche contextuelle.STD fait de la recherche un processus permanent qui nourrit les autres tout au long de la vie du système.

Si STD apporte quelque chose de propre, nous pensons que c’est de prendre pour objet l’évolution du système — et pas seulement la livraison d’un produit — et de se demander comment la synchronisation entre processus la modifie, y compris l’apparition de résultats que personne n’avait prévus.

Aspirations

A2Aspiration

Que chacun puisse appliquer et étudier SyncThinkDesign sans dépendre d’outils propriétaires.

A3Aspiration

Que des études soient menées par des tiers, y compris celles qui contredisent la proposition.

Références

  • Winner, R. I., et al. (1988). The Role of Concurrent Engineering in Weapons System Acquisition (IDA Report R-338). Institute for Defense Analyses.
  • Takeuchi, H., & Nonaka, I. (1986). The New New Product Development Game. Harvard Business Review, 64(1).
  • Holland, J. H. (1995). Hidden Order: How Adaptation Builds Complexity. Addison-Wesley.
  • Ries, E. (2011). The Lean Startup. Crown Business.
  • Schwaber, K., & Sutherland, J. (2020). The Scrum Guide.
  • Brown, T. (2008). Design Thinking. Harvard Business Review, 86(6), 84–92.
  • Kim, G., Humble, J., Debois, P., & Willis, J. (2016). The DevOps Handbook. IT Revolution.

Historique

VersionDateChangement
0.12026-10-27Première version documentaire. Elle réduisait la proposition à une définition opérationnelle centrée sur la détection d’hypothèses fausses.
0.22026-10-28La conception fondatrice est rétablie : la synchronisation comme nourriture mutuelle et continue, l’évolution, l’émergence, les systèmes adaptatifs et une portée transversale. La définition opérationnelle passe dans la formalisation, subordonnée à ces principes.