Comment mener des projets web et mobiles autrement

Roux et Fadel, ninjas du code informatique

Durant les projets web et mobiles, programmation et collaboration avec les clients sont des domaines souvent éloignés. Mais en utilisant les méthodes agiles, en tirant parti des nouveaux modes de collaboration, en repensant l’architecture et l’approche de programmation, cette distance disparaît. Nicolas Roux et Frédéric Fadel d’Aspectize en témoignent.

Réviser ses conduites de projets

Régulièrement le Chaos Report du Standish Group rappelle le médiocre taux de réussite des projets informatiques. Même si la tendance est à l’amélioration, les chiffres évoluent peu. Que dirait-on d’autres secteurs économiques s’ils connaissaient de tels résultats ? L’informatique est un métier récent, il s’est industrialisé depuis une soixantaine d’années. On pourrait lui imputer ces résultats à des erreurs de jeunesse.

On pourrait aussi s’interroger sur les méthodes et les façons de travailler. Si autant de projets échouent ou n’atteignent pas leurs objectifs, peut-être que les méthodes suivies sont à changer ou du moins à reconsidérer. C’est dans cet état d’esprit que Nicolas Roux et Frédéric Fadel ont créé leur entreprise, avec la volonté de changer la façon de conduire des projets de développement et de fabriquer des applications web et mobiles.

Séparer le métier et la technique

Esprit critique

Nos deux ingénieurs remettent en cause l’approche orientée objet, enseignée dans les écoles et pratiquée dans tous les projets informatiques. Elle mélange dans le code les aspects techniques et les aspects métiers.

Les aspects métiers varient en fonction des applications et des projets, et ils changent régulièrement. Les éléments techniques, c’est tout le contraire. Ces derniers se retrouvent dans une myriade de projets et d’applications. Ils sont invariants et relativement immuables. Et s’ils connaissent des ruptures technologiques fortes (Web, Cloud, mobilité), elles sont moins fréquentes que celles des métiers.

Devant ce constat, ils ont opéré trois choses. D’une part, ils ont séparé dans l’architecture les éléments métiers et les éléments techniques. D’autre part, ils ont développé les éléments techniques une bonne fois pour toutes ; étant des invariants, il est inutile à chaque projet de les réécrire. Ils ont ainsi démontré que cette séparation était réaliste. Ces éléments sont disponibles dans un moteur technique de leur propre création. En se branchant à ce moteur, le développeur accède à cette infrastructure technique, et peut se concentrer sur les éléments métiers.

Inverser les logiques

Enfin, ils ont inversé la dépendance entre le code technique et le code métier. Habituellement, pour créer des appli, le développeur utilise un framework, c’est-à-dire un ensemble de code packagé qui permet le développement et la maintenance de logiciels. Il écrit son code métier et utilise ce framework dans son code à l’aide d’API (interface de programmation applicative).

Nos ingénieurs ont inversé cette logique. Le développeur écrit son code métier, et c’est le framework qui appelle le code métier de l’utilisateur. Cette différence permet d’encapsuler de nombreuses fonctionnalités techniques, dont le développeur n’a plus à se préoccuper.

Conséquence de ces changements techniques : le cahier des charges, aussi laborieux et fastidieux à écrire qu’à lire, n’est plus nécessaire pour démarrer un projet – soit dit en passant, il finit bien souvent à la poubelle car le projet a évolué et s’est vite éloigné des idées initiales. Alors pourquoi en rédiger un ? De fait, le gain de temps est énorme. Et ils le consacrent à la relation avec leurs clients et la création de l’appli.

Vive les méthodes agiles !

Ecouter le client

En effet, au lieu de s’encombrer d’un cahier des charges, ils partent à la rencontre de leurs clients, essentiellement des gens du métier, avec qui ils discutent, échangent, interagissent. Un premier entretien dure environ 2-3 heures. Les clients précisent leurs attentes, racontent l’histoire de leur entreprise et leur travail quotidien… C’est une manière de connaître et d’évaluer leurs besoins : pourquoi veulent-ils une application, que souhaitent-ils en faire, quelles fonctionnalités recherchent-ils ? La relation gagne en qualité et en clarté.

Ces connaissances sont indispensables à une meilleure compréhension des futures fonctionnalités de l’appli. Certes, toutes les informations ne sont pas recueillies, mais en avoir l’exhaustivité n’est pas nécessaire. L’appli se fabrique progressivement, morceau par morceau, selon un cycle de production très court. Un cycle correspond toujours à un usage évoqué lors des échanges.

Cycle court et tolérance au changement

Dès le premier jour, le développement commence. A J + 1, les clients reçoivent quelques éléments visibles, la sécurité est présente avec la possibilité de créer un compte. Les itérations et la communication quotidiennes s’enclenchent. Ce mode de production est très linéaire. Si les développeurs estiment un travail de 100 jours, le jour 1, ils produiront 1 % de l’application, le deuxième jour, 2 %, etc. Si au 26^e jour, ils découvrent une erreur, ils ne se sont trompés que de quelques heures, et reviennent au jour précédent.

Ainsi, quand les clients demandent une évolution, ils l’apportent rapidement. Le temps de développement est très court. En effet, les pièces informatiques (code, données, éléments d’interface) sont indépendantes et le volume de code est réduit. Les évolutions, dont les conséquences sont minimales, peuvent se faire au fil de l’eau.

Cette réactivité permet une grande tolérance au changement et à l’erreur. Fini le temps où à la moindre demande de modification, à la moindre incompréhension, une foule de choses était à refaire. Adieu les négociations sans fin à cause d’une demande absente du cahier des charges. La production logicielle dit enfin oui !

DevOps : du nouveau pour les projets

Autre apport des méthodes agiles, DevOps. Grâce aux nombreux outils fournis par DevOps, le développeur effectue lui-même la phase de déploiement, de mise en production et de surveillance de la plateforme avant la livraison de l’application. En un clic de souris, dans le Cloud, il gère cette partie du projet ainsi que la gestion de versions.

Les outils de gestion de version sont des outils compliqués qui ont été rendus simples. Pratiquement, s’il y a une erreur, la gestion de versions permet au développeur de revenir à la version précédente et de corriger les bugs. Une telle méthode permet une très grande tolérance au changement et à la panne.