novembre 11

peanut : Les grandes lignes (techniques) de la v2

Suite à la définition du projet et la mise en place de la première brique d’industrialisation, il est maintenant temps de passer aux choses sérieuses, les bases techniques.

Le pourquoi de cette nouvelle version

Pour comprendre cette orientation CMF, je pense qu’il est important de vous situer mon expérience professionnelle :

2002 : Electricien dans le bâtiment en contrat d’apprentissage
2004 : Un peu d’événementiel dans le jeu vidéo (multitude de CDD, contrat à la sauvette et j’en passe)
2006 : Retour à l’informatique pour une année de Technicien d’Assistance Informatique. Accessoirement, découverte du web 2.0 aka « OH MON DIEU, JE SUIS UNE PUTE DU WEB »
2007 : Contrat de professionnalisation de TSSI mais surtout, premiers pas sur le web en tant qu’intégrateur avec un peu (en fait beaucoup) de wordpress
2008 : Début d’un projet web avec deux amis. Projet abandonné et op, un poste de webmaster chez geekspirit/mageekstore
Fin 2008 : Chef de projet multimédia pour une société de communication opérationnelle (ce qui veux dire : on fait de tout pour les grands comptes et agences)

Résultat des courses, je pense connaitre le monde professionnel à travers ses différents aspects et donc différentes problématiques. Pour moi, le monde de l’entreprise (notamment chez les grand compte) est vraiment quelque chose de fascinant et les possibilités pour le web sont presque infinies.

Le déclencheur est quant à lui une convention, puis une autre, et encore une autre, dans lesquelles j’ai pu entendre en tant que prestataire sur l’événement des demandes de salariés à une direction bloquée par un service informatique lui-même bloqué par une infrastructure difficile à remettre en question (ne jettons pas directement la pierre sur nos amis les DSI) ou tout simplement pour un manque de moyen humain.

Et dans tout ça, avec mon petit vécu professionnel, il se passe des choses dans ma tête pour finalement se dire qu’il y a quelque chose à faire.

Les problématiques entreprises (et grand-comptes)

Revenons à nos moutons, les entreprises. Tous les développeurs web ayant pu côtoyer ce monde connaissent les principales problématiques :

Une architecture réseau/informatique pas toujours à jour (bonjour IE6)
Des utilisateurs avec une demande mais peu de compétences informatique
Un SI omniprésent et verrouillant le maximum d’éléments vis à vis des prestataires externes (sauf quelques rares cas)

Coté humain :

Des services avec des demandes différentes
Des services ne fonctionnant pas ensemble
Des personnes (le manager en bout de chaine avec son responsable, son RH site, son RH groupe, sa comm’ site, sa comm’ groupe etc etc) qui ne demandent qu’à évoluer dans de bonnes conditions

Rajoutons à cela les problématiques multinationale :

L’échange d’informations et la communication

Heureusement pour nous, il existe un grand nombre de solutions. J’ai cependant isolé deux problèmes fondamentaux et omniprésents :

Le language : Dans les groupes, affronter les problématiques i18n et l10n est un vrai fardeau à cause du manque de connaissance et des moyens en place
L’échange d’informations utilisateurs : le fameux serveur Activ’Directory capable de faire tant de choses mais si peu utilisés. Pensons un peu plus loin et ramenons ça à une problématique de type LDAP

Le reste n’est que « de la routine » vis à vis des développements web conséquents : gestion des droits d’accès (permissions), multitude de site (sous domaines) et de besoins (op le réseau social interne, op le wiki…) Etc, etc.

On peut donc commencer à réfléchir.

Définir un socle technique

Une fois une partie des problématiques identifiées, nous pouvons définir le socle technique du projet. Arriver du jour au lendemain dans ce genre de structure pour dire « En 2011, on passe tout en PHP. Et puis en 2012, on passera tous sur Django et après tout en Java ! » est un peu stupide. Il faut arriver à penser sur une période un peu plus longue. On a donc concrètement cette problématique de language à prendre en compte mais aussi à essayer d’anticiper les besoins utilisateurs.

Le langage Forcément, sujet délicat. Je vais personnellement opter pour PHP (si vous ne l’aviez toujours pas compris). J’aurais pu en profiter pour me mettre à regarder tranquillement du coté de Django mais je ne préfère pas pour le projet. La première raison à ce choix est la (bonne) tournure que prends PHP. Un langage mature, disposant de framework orientés professionnels (symfony/zend), des méthodologies de travail, une industrialisation possible, une compatibilité avec la pluspart des technologies naissantes et surtout un bon vivier de développeurs à se mettre sous la dent. Bref, du tout bon pour notre SI qui ne demande qu’à pérenniser. Le choix de PHP permet également de plus petites entreprises de s’équiper avec un minimum de connaissances techniques (il est très facile de trouver une personne capable de mettre en place un serveur PHP) et les coûts sont faibles. Encore un bon point.

Ceci dit et je vous l’accorde volontier, il est difficile de savoir comment faire la différence entre les développeurs PHP. Le bon, la brute et le méchant version numérique.

Le framework PHP est une chose, un framework en est une autre. Le fait même de mettre en place un framework permet de faire un pas vers les bonnes pratiques web dans le sens large du terme. Les conventions de code, le modèle MVC et l’approche objets ne sont que quelques unes des bonnes raisons. Sur ce point, je reste avec symfony dans l’optique d’évoluer vers symfony2 (ce choix a déjà été expliqué) avec une implémentation de certains composants du Zend Framework.

Coté client : xHTML, HTML, CSS 1, 2,3, javascript, jquery, moofx… Op, un autre débat. Coupons cours direct et optons pour HTML5, CSS3 (à travers LESS) et jQuery malgré les problématiques liées à IE6. Pourquoi ? Dans un premier temps parce que les services informatiques vont forcément évoluer. IE6 représente de moins en moins de machine et n’est finalement la plus que pour une raison liées au système (Windows 2000, Windows XP) ou à une problématique web liées aux outils existants. A partir du moment où l’on remet l’un ou l’autre de ses éléments en cause, il faut évoluer. Le web ne doit pas être tiré vers le bas même dans le contexte entreprise. A l’opposé, il faut prendre en compte toutes ces problématiques et proposer quelque chose d’acceptable pour les personnes sous IE6. Enfin, pensons un peu aux terminaux mobiles.

Sémantique et accessibilité à l’information Toutes entreprise de plus de 50 salariés (si ma mémoire est bonne) se doit de respecter un « quota » de travailleurs avec un handicap (quel qu’il soit). Penser sémantique et accessibilité, c’est non-seulement pousser une application vers l’interopérabilité mais aussi en faciliter l’accès sur le long terme. Une entreprise dont la taille exige un certains nombres de travailleurs handicapés se doit d’être accessible pour la totalité de ses sites Internet.

L’industrialisation et les méthodes agiles Garantir la pérennité d’un projet sur le long terme passe par une industrialisation complète de la chaine de développement. Le produit de base peut avoir une durée de vie de 5 à 10 ans (si l’on prends le cas IE6), le nombre de personnes impliquées sur le projet n’est pas quantifiable et il faut donc fixer une méthode de travail efficace dès le début.

Conclusion

La réflexion ci-dessus correspond finalement à une expression initiale de besoins et est la première étape de l’utilisation de méthodes agiles (Scrum, XP…) ou encore en UML. On peut être d’accord ou non avec les informations ci-dessus mais les grandes lignes du projet sont définies. Nous allons enfin pouvoir commencer à travailler sérieusement

By Alexandre

Comments

Anarko_bizounours décembre 12th

Tu passes du CMS au CMF, interessant comme tournure du projet peanut. J’attend avec impatience de voir ce que ça va donner.