Convaincu par la puissance des API REST, séduit par les nouveaux framework JavaScript, vous avez décidé de passer d'une architecture traditionnelle à une dichotomie forte front end / back end. Félicitations ! C'est en effet une voie prometteuse.

Attention toutefois à ne pas négliger les conséquences de ces technologies en terme d'organisation de votre équipe.

Des promesses alléchantes

Dans l'esprit de beaucoup de monde, le passage au front end / back end signifie :

• Les développeurs back end se consacrent à la construction d'une API REST claire, efficace, polyvalente et performante.
• Les développeurs front end créent des UI attrayantes, ergonomiques et rapides, avec l'outillage qui leur est propre, en toute liberté par rapport au back end.

Certes, c'est bien l'objectif. On imagine bien d'ailleurs les uns et les autres se reformuler tout ça dans leur tête :

Back end : "Avant j'avais des tas de choses à faire, notamment tous ces écrans pénibles, maintenant au moins, je fais juste une API, c'est plus tranquille, je vais pouvoir faire des choses propres sans qu'on m'embête."

Front end : "Je vais pouvoir m'éclater à faire des supers interfaces, avant j'étais la cinquième roue du carrosse, je ne participais jamais aux décisions, on m'appelait juste pour faire le coloriage et toujours avec des plannings intenables, maintenant c'est moi qui gère."

D'un côté ou de l'autre, c'est vrai que c'est alléchant.

Mais il y a un piège.

Le travail reste le même

Dire que le back end se concentre sur une API REST, c'est aussi dire qu'il ne s'occupe plus du tout de la couche de présentation, ce qui recouvre beaucoup de choses (UI et conception fonctionnelle, certes, mais aussi conception technique, découpage des responsabilités entre composants, re-factorisation quand c'est nécessaire…).

Donc tout ça, côté back end, on ne s'en occupe plus. Et donc qui s'en chargera ? Le front end, forcément.

Ce sera désormais son travail. Cela peut sembler évident quand on le présente ainsi, mais bien souvent, on l'oublie. Ce qui jusqu'ici était de la responsabilité de l'équipe back end ne disparaît pas par la grâce de marraine la bonne fée, passé minuit, le bal est fini, le prince back end est rentré, et on se retrouve avec tout le travail sur les bras.

Et pour l'équipe front end, c'est un travail d'autant plus rude que, d'une part, elle a déjà beaucoup de travail, et d'autre part cela sort de ses compétences habituelles. En effet, si on prend un expert en CSS qui savait manipuler une multitude de plugins jQuery, et qu'on lui demande de développer des modèles objets et d'utiliser des patterns complexes, la transition est difficile. Non pas qu'il n'en soit pas capable la plupart du temps, mais simplement parce que cela ne s'improvise pas du jour au lendemain.

Donc, si le passage au front end / back end se traduit par une équipe back end heureuse mais relativement désœuvrée, et une équipe front end surchargée de travail pour lequel elle n'est pas expérimentée, on comprend bien que cela se terminera par un échec.

Adapter les équipes

La mesure la plus pragmatique à prendre consiste à marier les deux équipes, ou en tout cas, à les croiser.

Les différentes tâches à accomplir pour créer une application sont toujours là, elles sont simplement traitées par des technologies front plutôt que back. En toute logique, une partie de ceux qui assuraient ces tâches côté back end doivent passer côté front afin d'apporter leur expérience et leur savoir-faire à l'équipe front end.

C'est la première raison qui doit amener à renforcer l'équipe front end.

La seconde, c'est simplement l'inflation naturelle du développement web : on fait désormais des applications web plus compliquées qu'avant. D'une part parce qu'on peut le faire (la technologie le permet), et d'autre part car les utilisateurs le demandent. Et donc la part du front end va de toute façon augmenter et coûter plus.

Vous vous posez des questions sur le développement front end ?