Idée principale

Le logiciel a connu une période où des analystes spécifiaient et où des programmeurs produisaient du code au kilomètre. Les uns pensaient, les autres exécutaient. Ce découpage a disparu : un développeur prend aujourd'hui un problème de bout en bout — architecture, code, sécurité, livraison, suivi — et même les architectes séparés du reste de l'équipe se raréfient.

Personne ne demande le retour des analystes-programmeurs, et personne ne soutient qu'on écrivait un meilleur logiciel quand la réflexion et l'exécution vivaient dans deux têtes différentes. Le métier a tranché par l'usage, sans théorie.

Ce précédent a valeur d'argument : la même ligne de coupe, déplacée du code vers le produit, doit expliquer pourquoi elle échapperait au sort de la précédente. La charge de la preuve change de camp.

Pourquoi c'est important

Cela transforme une opinion sur l'organisation produit en question historique vérifiable : la séparation conception / exécution a déjà été essayée à grande échelle dans le même secteur, et elle a été abandonnée.

Cela fournit aussi une trajectoire probable plutôt qu'un simple désaccord : les découpages de ce type reculent quand l'outillage réduit le coût de faire les deux.

Nuances et limites

Un précédent n'est pas une preuve. Le développement a eu des raisons propres de recoudre les deux moitiés — cycles courts, intégration continue, coût du retour arrière — et rien ne garantit que ces raisons se transposent au produit.

Et l'abandon n'a pas été total : des rôles d'architecte, de staff engineer ou de tech lead subsistent, avec une part de conception distincte de l'exécution. Ce qui a disparu est la courroie de transmission, pas toute spécialisation.

Questions ouvertes

• Quelles conditions techniques ont réellement permis de recoudre conception et exécution côté développement, et lesquelles existent aujourd'hui côté produit ?