Il suffit de feuilleter le TCE pour voir que l'UE a dépassé le cadre d'une communauté économique. Il doit bien y avoir une raison pour laquelle on ne dit plus CEE, d'ailleurs. En ce qui me concerne, je suis pour que l'UE se définisse une politique économique, et ce n'est pas incompatible avec une séparation entre objectifs et moyens.
Pour faire une analogie informatique (j'aime bien les analogies, oui :), pour moi il faut séparer le design de l'implémentation. Quand tu fais une bibliothèque de structures de données, tu définis des opérations comme le tri, mais tu gardes une certaine distance vis à vis de l'implémentation, qui permet par la suite de changer d'algorithme de tri, pour une raison ou pour une autre. On considère en général que c'est une bonne chose d'avoir un document court et synthétique contenant la définition des opérations (l'API) d'une part, et d'autre part le code source contenant l'implémentation.
Pour définir l'UE c'est pareil, on peut tout à fait imaginer que la communauté soit définie par un texte qui énumère ses institutions, ses objectifs (par exemple le plein emploi), etc. sans que soient définis les moyens par lesquels on compte atteindre ces objectifs (l'implémentation). On peut tout à fait y mettre des objectifs économiques, et pas les outils utilisés. Les outils, eux, doivent être définissables de manière plus souple (c'est d'ailleurs pour ça que la partie III est plus facilement réformable).
L'avantage de ce découpage c'est que l'on peut changer l'implémentation sans changer le texte de référence. Ça a fait ses preuves dans plein de domaines, ça doit donc être applicable aussi en politique (et d'ailleurs on l'applique tous les jours à l'échelle des États).
[^] # Re: pas faux
Posté par Yusei (Mastodon) . En réponse au journal réflexions brutes. Évalué à 1.
Pour faire une analogie informatique (j'aime bien les analogies, oui :), pour moi il faut séparer le design de l'implémentation. Quand tu fais une bibliothèque de structures de données, tu définis des opérations comme le tri, mais tu gardes une certaine distance vis à vis de l'implémentation, qui permet par la suite de changer d'algorithme de tri, pour une raison ou pour une autre. On considère en général que c'est une bonne chose d'avoir un document court et synthétique contenant la définition des opérations (l'API) d'une part, et d'autre part le code source contenant l'implémentation.
Pour définir l'UE c'est pareil, on peut tout à fait imaginer que la communauté soit définie par un texte qui énumère ses institutions, ses objectifs (par exemple le plein emploi), etc. sans que soient définis les moyens par lesquels on compte atteindre ces objectifs (l'implémentation). On peut tout à fait y mettre des objectifs économiques, et pas les outils utilisés. Les outils, eux, doivent être définissables de manière plus souple (c'est d'ailleurs pour ça que la partie III est plus facilement réformable).
L'avantage de ce découpage c'est que l'on peut changer l'implémentation sans changer le texte de référence. Ça a fait ses preuves dans plein de domaines, ça doit donc être applicable aussi en politique (et d'ailleurs on l'applique tous les jours à l'échelle des États).