Framework

C’est une dépendance, et elle est réelle. Adopter un framework engage durablement : changer de cadre en cours de route revient à reconstruire. Il n’existe pourtant aucune option sans dépendance, un développement sans cadre dépendant, lui, de son auteur. La vraie question n’est donc jamais « comment éviter la dépendance ? » mais « cette dépendance est-elle partagée par beaucoup de monde et durable ? ». Un framework répandu est une dépendance que des milliers de professionnels connaissent, ce qui n’est pas le cas d’un code écrit à part.

Le cadre peut faire oublier ce qu’il y a dessous. Tous les développeurs ne savent pas travailler à bas niveau, en PHP seul, hors du confort des outils fournis. Tant que tout se passe bien, la différence ne se voit pas. Elle apparaît le jour d’un comportement inattendu, d’une optimisation fine ou d’une intégration que le cadre n’avait pas prévue. C’est un critère à garder en tête lorsque vous confiez un projet exigeant : la maîtrise du framework et la maîtrise des fondations ne sont pas la même compétence.

Un framework ne remplace ni la conception ni l’entretien. Il fournit des fondations saines, pas une application bien pensée. Un projet mal cadré au départ le restera, quel que soit le cadre technique. Et les briques fournies exigent leurs mises à jour, comme le reste : un framework laissé plusieurs années sans montée de version accumule les mêmes retards qu’un site laissé sur une vieille version de PHP. C’est précisément l’objet d’un suivi en maintenance applicative.

Le framework à la mode d’hier est le projet à reprendre d’aujourd’hui. Nous voyons régulièrement des applications construites sur des cadres qui faisaient l’unanimité il y a quelques années et que plus personne n’entretient. Le code fonctionne encore, mais il n’évolue plus sans coût, et le vivier de développeurs s’est déplacé ailleurs. Ce n’est pas un accident, c’est la conséquence prévisible d’un choix fait sur l’enthousiasme du moment plutôt que sur la durée.