Le design, c’est aussi la manière dont une chose évolue

§Point de départ

Presque toutes les méthodes pour construire quelque chose s’expliquent comme une séquence : d’abord on comprend le problème, puis on conçoit, puis on construit et, à la fin, on mesure. La séquence est utile pour enseigner, parce qu’elle met de l’ordre dans ce qui ressemblerait sinon à un chaos. Mais le travail réel se comporte rarement ainsi, et ceux qui construisent des choses le savent, même s’ils continuent à dessiner la flèche de gauche à droite.

Ce qu’on apprend en construisant change ce qu’il fallait construire. Ce qu’on observe quand un système est en usage change ce qu’on croyait en avoir compris. Quand une méthode oblige cette information à attendre la clôture d’une phase, elle arrive tard, ou n’arrive pas du tout. Et le système qui en résulte est celui qu’on avait planifié au début, pas celui dont le travail lui-même montrait le besoin.

§Ce que nous proposons

SyncThinkDesign part de quatre processus : Capter (Sync), Concevoir (Think), Exécuter (Design) et Optimiser (Refine). Nous ne les comprenons pas comme des étapes qui se succèdent, mais comme des processus qui peuvent fonctionner en parallèle, se nourrir les uns les autres et modifier l’évolution d’un système pendant que ce système est conçu, construit et utilisé.

Synchroniser ne veut pas dire tout faire en même temps ni répondre en zéro seconde. Cela veut dire que ce qui se passe dans un processus peut agir sur les autres sans attendre qu’une phase se termine. Le temps que met cette influence dépend de la nature du système : dans un logiciel, quelques minutes ; dans une organisation, des semaines ; dans une œuvre, le temps qu’il faut à une conversation pour revenir jusqu’à l’atelier.

De cette interaction continue naît l’autre idée centrale : les systèmes évoluent de manière organique. Ils changent d’objectifs, de structure, de composants et de comportement pendant qu’on les construit et qu’on les utilise, et une partie de ce qu’ils deviennent ne figurait dans aucun plan initial. Nous n’y voyons pas un échec de planification, mais ce qui arrive quand ce que l’on apprend a le droit de modifier ce que l’on fait.

§Convictions

• La synchronisation plutôt que la fragmentation. Capter, concevoir, exécuter et optimiser se nourrissent mutuellement ; les cloisonner en phases étanches coupe précisément les échanges qui comptent le plus.
• L’évolution organique plutôt que les séquences rigides. Un projet n’a pas à attendre la fin d’un cycle pour intégrer ce qu’il vient d’apprendre. Les itérations ont leur place dans une évolution continue ; ce que nous remettons en question, c’est l’attente.
• L’émergence plutôt que la planification exhaustive. Les meilleures solutions naissent souvent de l’interaction entre processus, et non d’un plan qui prétend tout anticiper.
• Des systèmes adaptatifs plutôt que des produits figés. Un projet ressemble davantage à quelque chose de vivant qu’à un artefact achevé. C’est une analogie, pas une affirmation biologique, et nous l’employons parce qu’elle décrit bien ce que nous voulons observer.
• Validation et optimisation intégrées. Valider et améliorer ne sont pas des phases qui viennent à la fin ; elles ont lieu pendant que le système évolue.
• La complexité comme source possible. La complexité et l’incertitude ne sont pas seulement des obstacles : elles peuvent être le lieu d’où surgissent des solutions que personne n’aurait planifiées.

Chacune de ces convictions est développée en principe dans les fondements.

§Le design comme évolution

Le design n’est pas seulement l’apparence d’une chose, ni seulement son fonctionnement. C’est aussi la manière dont elle évolue : ce qui peut changer, quelle information la fait changer et qui peut intervenir dans ce changement. Concevoir un système, en ce sens, c’est aussi concevoir sa capacité à continuer de se transformer après qu’on l’a déclaré terminé.

§Ce que nous n’affirmons pas

SyncThinkDesign n’est ni un produit ni un service, et n’exige aucun outil particulier. Elle ne remplace ni Scrum, ni Lean, ni le Design Thinking, ni DevOps ; dans bien des cas, elle peut coexister avec eux. Et elle n’est pas démontrée. Nous pensons que synchroniser les processus peut raccourcir les délais, accroître la capacité d’adaptation, améliorer la qualité et favoriser des solutions imprévues, mais ce sont des hypothèses, écrites comme telles dans la formalisation pour pouvoir être mises à l’épreuve.

Nous ne prétendons pas non plus que tout ce que nous soutenons soit mesurable aujourd’hui. Certaines convictions sont une manière de regarder le travail plutôt qu’une prédiction. Nous ne les supprimerons pas faute de données ; nous les distinguerons soigneusement de ce qui peut être vérifié.

§Pourquoi l’examiner maintenant

Certains outils rendent visible ce qui était difficile à observer. Chez Braidata, nous développons des applications — nous les appelons AAA3 — où le projet est décrit dans un document que des personnes, des scripts et des modèles de langage peuvent lire et modifier, et où les changements peuvent être versionnés et comparés. Dans de tels environnements, on peut suivre en détail comment l’information d’un processus modifie les autres et comment le résultat évolue. Et quand les agents d’IA rendent la conception et la construction moins coûteuses, la question de la synchronisation des processus cesse d’être théorique.

Mais SyncThinkDesign ne dépend pas de ces outils. La question qui nous intéresse est la même dans une équipe logicielle, une organisation, une salle de classe ou un processus créatif : comment la synchronisation entre processus influence-t-elle l’évolution d’un système, et dans quelles conditions apparaît ce que personne n’avait prévu ?

§Ce qui nous la ferait réviser

Une proposition qui ne peut pas avoir tort ne sert à rien. Ces observations nous obligeraient à la réviser :

• Que la synchronisation des processus ne change pas sensiblement l’évolution d’un système, par rapport à des phases bien coordonnées.
• Que les résultats imprévus ne soient pas plus fréquents, ou qu’ils ne se révèlent presque jamais précieux.
• Que le coût de la coordination de processus en parallèle dépasse systématiquement ce qu’elle apporte.
• Que ce que nous appelons synchronisation se révèle, en pratique, indiscernable d’une bonne itération.

Si l’une de ces choses s’avère vraie, nous voulons le savoir. La section discussion explique comment.

Iván BraidaVersion 0.2 · 2026-10-28