On vous a menti dès le premier jour de votre formation en informatique. On vous a montré ces arborescences soignées dans votre environnement de développement, ces petits dossiers imbriqués les uns dans les autres qui suggèrent une structure familiale, où le dossier parent protège et englobe ses enfants. Vous avez cru, naturellement, que déclarer un Java Package In A Package créait une relation de subordination logique et technique. C’est une erreur fondamentale. Pour la machine virtuelle Java, la notion de sous-paquetage est une pure fiction marketing, un mirage visuel destiné à rassurer l'esprit humain assoiffé d'ordre, alors qu'en réalité, chaque espace de nommage est une île totalement isolée.
Le problème réside dans notre perception physique des fichiers. Parce que nous voyons des répertoires sur un disque dur, nous projetons des propriétés d'héritage là où il n'y a que de la nomenclature plate. Si vous placez une classe dans un dossier nommé util et une autre dans util.concurrent, le langage ne voit aucun lien de parenté entre elles. Elles sont aussi étrangères l'une à l'autre que deux classes situées dans des projets radicalement différents. Cette méprise coûte cher aux entreprises : elle engendre des architectures fragiles où les développeurs pensent bénéficier d'une encapsulation naturelle alors qu'ils laissent les portes de leur code grandes ouvertes, ou au contraire, s'enferment dans des structures inutilement complexes.
Le mythe technique du Java Package In A Package
L'idée même d'une imbrication fonctionnelle s'effondre dès qu'on touche aux modificateurs d'accès. La plupart des ingénieurs pensent que le niveau de visibilité par défaut, celui qu'on appelle souvent package-private, permet aux classes d'un dossier parent d'accéder aux membres des classes situées dans les dossiers enfants. C'est faux. Une classe située dans la racine de votre projet ne possède aucun droit spécial sur ce que vous appelez par abus de langage un Java Package In A Package. Pour le compilateur, le point qui sépare les noms n'est pas un opérateur d'accès ou une preuve de descendance, c'est juste un caractère comme un autre dans une chaîne de caractères unique.
Cette réalité technique crée un fossé immense entre l'intention de l'architecte et l'exécution du code. Je vois quotidiennement des systèmes où l'on multiplie les niveaux de dossiers en pensant organiser la logique métier, alors qu'on ne fait que rallonger les déclarations d'importation sans rien protéger du tout. Java a été conçu avec une structure de nommage globale, plane. L'illusion de la profondeur n'est qu'une couche de peinture appliquée par les outils de gestion de fichiers. James Gosling et son équipe n'ont jamais voulu créer un système de poupées russes. Ils ont créé un système d'étiquetage. Si vous ne comprenez pas que chaque étiquette est indépendante, vous ne programmez pas en Java, vous jouez aux Lego avec des briques qui ne s'emboîtent pas.
L'échec de l'encapsulation par l'arborescence virtuelle
Si l'on observe la manière dont les grands frameworks gèrent leurs structures, on s'aperçoit que la confusion entre organisation visuelle et sécurité du code est la source principale de fuites d'abstraction. Prenons un exemple illustratif. Un développeur senior décide de scinder un module de paiement en créant des dossiers séparés pour le traitement par carte et le virement bancaire. Il imagine que la logique centrale pourra piocher dans ces composants tout en les gardant isolés du reste du monde. Mais comme il n'y a pas de véritable relation entre le conteneur et le contenu, il finit par déclarer toutes ses classes comme publiques. À cet instant précis, l'organisation en dossiers ne sert plus à rien. N'importe quelle partie du logiciel, même la plus éloignée, peut désormais manipuler ces composants internes.
On sacrifie la sécurité sur l'autel de la propreté apparente. En France, les écoles d'ingénieurs insistent lourdement sur la conception orientée objet, mais elles oublient souvent de préciser que le Java Package In A Package n'offre aucune barrière de sécurité supplémentaire. C'est un simple système de tri postal. On trie le courrier par code postal, mais le fait qu'un code commence par les mêmes chiffres qu'un autre ne donne pas au voisin le droit d'ouvrir votre boîte aux lettres. Cette absence de hiérarchie réelle signifie que si vous voulez vraiment isoler votre code, vous devez arrêter de vous fier à la structure des dossiers et commencer à utiliser les modules introduits avec Java 9, ou accepter que chaque paquet est une entité souveraine.
Le système de modules, justement, a été la réponse tardive et brutale d'Oracle à cette croyance populaire. Les experts savaient que l'organisation par points était un échec pour la sécurité à grande échelle. Le Project Jigsaw n'est rien d'autre que l'aveu que nos structures de dossiers étaient une façade. En forçant les développeurs à déclarer explicitement ce qu'ils exportent, Java a enfin brisé le fantasme de la hiérarchie implicite. Pourtant, même aujourd'hui, combien de projets continuent de s'empiler sans aucune réflexion sur la visibilité réelle, sous prétexte que c'est bien rangé ?
Une architecture plate pour des systèmes complexes
La solution n'est pas de créer plus de dossiers, mais de réduire notre dépendance psychologique à leur égard. J'ai vu des projets réussir magnifiquement avec une structure presque plate, où la séparation des responsabilités était dictée par des interfaces strictes plutôt que par une géographie complexe. Quand on accepte que l'imbrication n'existe pas, on commence à écrire du code plus robuste. On arrête de supposer qu'une classe est protégée parce qu'elle se trouve au fond d'un labyrinthe de répertoires. On traite chaque paquet comme un micro-service interne, avec une API claire et une surface d'exposition minimale.
On peut se demander pourquoi cette croyance persiste malgré les preuves techniques. La réponse est culturelle. Nous avons besoin de catégoriser. L'esprit humain refuse de gérer une liste de mille éléments sans les regrouper. Mais en programmation, ce besoin de confort cognitif devient un piège quand il ne correspond à aucune réalité d'exécution. Si vous pensez que vos sous-structures communiquent mieux entre elles, vous faites une erreur de jugement qui mènera inévitablement à des dépendances cycliques cachées. Le compilateur se moque de votre sens de l'esthétique. Il voit des noms complets, des Fully Qualified Names, et rien d'autre.
Il est temps de traiter l'organisation de votre code pour ce qu'elle est : un outil de recherche pour l'humain, pas une règle de sécurité pour la machine. Cette distinction est le seul moyen de construire des systèmes qui ne s'effondrent pas sous leur propre poids bureaucratique. Le véritable expert sait que le rangement n'est pas l'architecture. L'architecture, c'est la gestion des flux et des accès, et dans ce domaine, la proximité visuelle est souvent le pire ennemi de la rigueur technique.
Votre structure de dossiers est une carte qui ne représente pas le terrain, et continuer à croire que l'emplacement d'un fichier définit sa sécurité est la plus grande illusion de l'ingénierie logicielle moderne.
