Formations :

  • Baccalauréat scientifique spécialité Physique/Chimie
  • DEUG Science de la Matière
  • Titre professionnel de Développeur Informatique

Expériences professionnelles :

  • 2008 Dev-Solutions (Isle sur la Sorgue)

Directeur de développement, gérant : Développement d'applications web sur des technologies libres.

  • 2007 Cyberprod (Nice)

Développeur web : Développement d'applications web d'envergure sur une plateforme de production Symfony. Définition du modèle de données après analyse des besoins fonctionnels du projet.

  • 2006 Kaliop (Montpellier)

Développeur web : Développement d'applications web autour des technologies Open Source PHP/mySQL, déploiement de CMS (Spip, ezPublish).

Compétences techniques :

Développement applicatif côté serveur

Le web implique de mettre en place des architectures applicatives séparées en plusieurs couches afin d'obtenir une application cohérente, c'est ainsi que nous ferons la distinction entre les couches serveurs et les couches clientes.

C'est depuis la version 5 de PHP que je me suis intéressé professionnellement à cette technologie qui présente de nombreux avantages (licence libre, communauté active, fonctionnalités largement aussi fournies que ces concurrents). C'est également depuis cette version qu'ont commencé à fleurir les framework PHP, sur-couche indispensable à un développement agile de qualité.

Aprés avoir essayé des framework tels que cake, prado, ezComponents... je me suis naturellement orienté vers le framework symfony pour son implémentation du pattern MVC et sa flexibilité. J'ai participé à de nombreux projets depuis la version 1.0 du framework il y a quelques années. Les applications web modernes nécessitent de plus en plus de conception métier, un framework tel que symfony permet de se concentrer au maximum sur cette couche en s'affranchissant de toutes les couches rébarbatives d'un développement (mise en place des contrôle de données, écriture des classes d'abstraction du modèle de données...).

Comme sur tout développement, le développement côté serveur implique la mise en place et le respect de « bonnes pratiques », ainsi il est de rigueur de ne pas se répéter (Do not Repeat Yourself), de rester le plus simple possible (KISS) et d'élaborer des design pattern en adéquation avec le résultat de l'analyse. Je passerai rapidement sur mySql dont je maîtrise l'optimisation et dont je connais le fonctionnement détaillé de la plupart des moteurs de stockage (il est important de regarder sous le capot avant de choisir sa monture!).

Pour l'abstraction des données, j'ai choisi l'ORM Doctrine pour sa simplicité de prise en main grâce au respect du pattern ActiveRecords. C'est un ORM qui moyennant quelques techniques d'optimisation permet de manipuler un maximum de données en exécutant un minimum de requêtes, on retiendra aussi la possibilité d'instancier des transactions.

Les nouvelles approches de modélisation de données, permettant de franchir les limites des moteurs transactionnels, suscitent également mon plus grand intérêt, je pense notamment à Cassandra en court de test dans mon laboratoire, qui permet de faire du stockage très volumineux (cf Facebook).

Développement interfaces orientées objet

Le web implique quelques contraintes sur la partie cliente très souvent limitée aux interfaces, bien que l'apparition des API déconnectées tels que gGears contrarient un peu ce fondement.

Les standards du web sont pour moi la base de toutes interfaces, je n'utilise aucune technologie propriétaire telles que Flash, SiverLight mais me contente de monter des interfaces ergonomiques et navigables.

Le javascript allié à un framework moderne tel que mootools permet de monter des interfaces orientées objets très simplement. Je ne m'étendrai pas sur le sujet, une démo visuelle serait plus appropriée. J'axe actuellement ma veille sur canvas et ses contextes 2D et 3D qui à mon avis représentent l'avenir des RIA.

Administration de serveurs linux

Le développement d'application côté serveur implique la maîtrise du dit serveur. J'administre des serveurs web depuis plus de cinq ans, c'est devenu pour moi une seconde spécialité (une extension de mon métier). Aujourd'hui je me retrouve avec un trousseau de plus de dix serveurs dédiés tous en parfaite santé, monitorés, sécurisés.

Selon les besoins j'installe des serveurs web : apache pour les petits besoins (simple à déployer), de nombreux modules pour de nombreuses problématiques, nginx / montgrel pour des besoins de performance.

Côté distribution : debian ou centOs selon les besoins encore une fois.

Serveur de mail : Postfix / spamAssassin

Pour les besoins de disponibilité et de performance :

  • mirroring
  • clustering
  • load balancing

Et surtout pour la pérennité des systèmes : une grande veille sécuritaire.

Gestion de projet

Mener un projet technique, qu'il soit un simple site web, une application du type extranet ou une architecture serveur logiciel et matérielle, requiert un savoir faire, une culture et une méthodologie établie.

Bien avant d'effectuer le moindre choix techniques il faut établir avec précision les besoins du client, c'est l'étape la plus importante dans la gestion d'un projet. Pour ma part, j'estime que la captures des besoins fonctionnels doit être une opération réalisée avant même toute émission de devis. C'est cette étape qui va permettre de déduire les solutions techniques à envisager en fonction des subtilités, des contraintes métiers et des perspectives d'évolutions. Quoi de plus frustrant pour un directeur de projet que de réaliser un développement sur une technologie totalement inadaptée aux besoins du client. C'est pourquoi la notion d'équipe doit déjà apparaître lors de la phase commerciale : les commerciaux, l'équipe technique (ou son / ses représentants) et tous les intervenants du projet doivent échanger dans l'optique d'élaborer une proposition parfaitement en adéquation avec les problématiques métiers à résoudre. Être agile est une très bonne chose, être trop agile peut très vite devenir un vrai cauchemar (dépassement de délais, changements trop coûteux...). C'est pour cela qu'une bonne capture des besoins fonctionnels et le choix d'une bonne méthode de gestion de projet sont essentiels au bon déroulement d'un projet.

Après avoir avalé bon nombre d'ouvrages sur les différentes méthodes agiles et autres eXtrem Programming, on se rend rapidement compte que les différentes idéologies exprimées, certes très louables, représentent un idéal qui ne peut malheureusement que très rarement coller à la réalité. Ceci pour plein de raisons et facteurs qu'on ne peut malheureusement pas toujours maîtriser et anticiper. C'est donc naturellement que je me suis porté vers la méthode SCRUM qui est pour moi la plus réaliste si on veut conserver une cohérence et que la notion d'équipe ne fasse pas disparaître la notion de responsabilité. L'intégration du client est totale bien entendu mais implique une protection de l'équipe technique. Je ne rentrerai pas dans le détails ici des fondements de cette méthode, mais je vous invite à suivre ce lien si vous souhaiter en connaître les grandes lignes : http://fr.wikipedia.org/wiki/Scrum

Qui dit équipe dit besoin de centraliser toutes les ressources relatives au projet, pour ceci j'ai pour habitude de commencer par mettre en place un logiciel de suivi de projet qui va servir d'interface graphique à tous les acteurs : client, commerciaux, développeurs, analystes, graphistes... Les logiciels de gestion de projet (libres ou non) sont très nombreux mais n'apportent pas tous une simplicité d'utilisation à la protée de tous. Pour ma part, j'ai choisi redmine qui est pour moi largement suffisant pour la gestion de projet quelle qu'en soit l'ampleur. Il permet de gérer des tickets (demandes, bogues...) dans un workflow configurable, de gérer des versions cibles (itérations), de gérer les temps (GANT), de visualiser les dépôts de sources, WIKI, forum... Ainsi plus aucune communication non maîtrisable (mail, téléphone...) n'est nécessaire : toute demande persiste et une visue globale est possible. Bien sûr il faut éviter de dématérialiser au point d'oublier que les échanges humains font la pérennité de toute collaboration.

Pour ce qui est de la centralisation des sources je mets en place des dépôts structurés et imbriqués pour permettre de déployer et de mettre à jour les applications avec le plus de simplicité possible. Ainsi les plugins ont leurs propres dépôts inclus par références externes dans les applications. Un plugin amélioré et mis à jour pourra aisément être déployé sur l'ensemble des applications qui l'utilisent. Je vous invite à visiter http://www.fri-dev.com qui devient mon laboratoire de plugins et snippets personnels. Subversion reste le gestionnaire de source le plus adéquat et maitrisé par les développeurs malgré l'apparition de git qui n'apporte aucune réelle valeur ajoutée (côté utilisation j'entends). Pour des projets de plus grande envergure, un gestionnaire de sources décentralisé tel que Mercurial peut s'avérer être nécessaire. Pour ce qui est de la modélisation, UML reste toujours le langage le plus adéquat, même si celle ci est réalisée de façon ponctuelle avant chaque itération, voir chaque sprint.