Loading...En tant que directeur de projets chez Pentalog (SSII), je partage mon temps entre deux grandes activités : l’avant-vente et le suivi opérationnel des projets IT qui me sont confiés. Je suis donc amené avec l’aide de nos architectes à conseiller et accompagner mes clients sur leurs choix d’architecture, puis à suivre sa mise en place et sa bonne utilisation. Comme la plupart de mes collègues, je dispose d’une expérience passée dans le domaine du développement et de la gestion de projet, par essence très diversifiée puisque j’ai forgé mon expérience dans une SSII et côtoyé à ce titre un grand nombre de domaines / clients / technologies différentes.
L’architecture d’un projet informatique peut être définie selon ces axes principaux : les outils de développement, les logiciels et librairies tierces utilisées, le découpage en modules et la topologie des équipements
Voici quelques conseils, issus de mon expérience en tant que développeur, puis chef de projet et maintenant Directeur de projets, pour vous aider à faire le bon choix :
1) Impliquez un architecte, surtout en début de projet IT: c’est un conseil évident et pourtant pas toujours appliqué. Je préconise un élément fort techniquement qui s’assurera que les premiers développements sont conformes à l’architecture choisie, et que le projet démarre sur un socle solide. Cette personne peut travailler pour le client ou le prestataire.
2) Réutilisez au maximum des briques Open Source : on bénéficie gratuitement du travail réalisé par une communauté, c’est une solution qui se démocratise dans le monde de l’IT. Attention toutefois à investir suffisamment dans une étude préalable pour ne pas choisir un outil qui vous mènera dans une impasse (multiplication des branches, abandon par la communauté, basculement vers un mode payant, temps de customisation excessifs).
3) Ne vous interdisez pas d’acheter une licence, même si le projet est basé sur des outils Open Source. L’éventail de choix est large dans le domaine du gratuit, mais parfois un investissement de quelques centaines d’euros pour une librairie payante vous économisera de longues journées de développement.
4) Privilégiez les architectures SOA. Les Service Oriented Architectures présentent de nombreux avantages : en plus de rendre votre application ouverte et extensible, cette architecture permet de cloisonner les modules et de les faire communiquer par des protocoles standardisés. De cette façon si l’un de vos modules devient obsolète (par exemple un client web en HTML standard) il peut être complété ou redéveloppé avec une technologie plus moderne (client natif IPhone/IPad, HTML5 etc…) sans impact sur le reste du système.
5) Réalisez des POC. N’hésitez pas à investir quelques jours de développement dans un Proof Of Concept, qui vous permettra d’éprouver l’architecture choisie et de limiter le risque de partir sur une mauvaise solution technologique. C’est également un bon moyen de montrer au client un premier aperçu de ce que sera son logiciel, et de fournir une base de travail à l’équipe de développement qui pourra démarrer plus rapidement.
6) Attention aux technologies de développement « exotiques » : sortir des sentiers battus est séduisant, parfois efficace mais extrêmement dangereux. Il n’est pas rare de voir ce type de projet s’effondrer à cause de la difficulté à recruter des profils qui maîtrisent la technologie ou devant des obstacles posés par une technologie qui n’est pas mature. A utiliser en ayant conscience des risques que ça implique.
7) Étendez vos recherches à l’international. Les bonnes solutions sont également à l’étranger. Dans vos recherches sur le web pour identifier de nouvelles options pour votre architecture, ne vous limitez pas à des termes français mais utilisez également des termes anglais.
A titre d’information voici le TOP 5 des technologies utilisées sur les projets IT Pentalog depuis janvier 2010 :
- 1. JAVA
- 2. Développements Embedded (regroupant différents langages)
- 3. PHP
- 4. .NET
- 5. Business Intelligence
Certains points méritent qu’on y revienne plus en détail, c’est ce que je ferai lors d’un prochain article.
Gregory
mai 27, 2011 à 14:17Nous discutions justement hier soir avec un client de Pentalog (pour lequel nous avons une équipe offshore dédiée de 25 personnes travaillant sur des technologie .NET) sur le danger d’avoir un architecte trop féru (/trop geek!) de technologie. Il aura tendance à vouloir se faire plaisir en essayant de combiner les toutes dernières technologies du moment. C’est un risque majeur pour le projet car cela va pénaliser l’ensemble des développements qui suivront car les équipes se verront confrontées à des problèmes techniques pour lesquels il n’existe que très peu voir aucun retour d’expérience. Il faut donc prêter une très grande attention aux exigences du client, fonctionnelles bien sur mais aussi techniques pour ne pas designer une Ferrari alors qu’une Clio (no offense!) serait amplement suffisante !!
Sébastien Louchart
octobre 21, 2011 à 13:20Un architecte IT est comme son alter-ego du génie civil. Un concepteur. Un architecte a une connaissance succincte de la technologie néanmoins suffisante pour en connaître l’applicabilité. Je « plusseoie » Greg, l’implication architecte /technologie est tout sauf nécessaire. Et comme je suis légitime pour le dire, j’ajouterais même qu’il est nécessaire pour être un bon architecte de ne surtout pas promouvoir un produit ou une technologie. L’architecture est l’adéquation des moyens aux buts dans un souci d’efficacité, d’esthétique et d’harmonie. Cela vaut en génie civil, ça vaut aussi en IT.
L’architecture c’est le plan stratégique de l’application. les choix technologiques en sont de la tactique. On ne gagne pas une guerre avec de bons tacticiens mais on évite de la perdre.
L’autre remarque concerne SOA. Si les principes architecturaux devraient en être appliqués par tout projet sérieux, ils le sont généralement mal ou incomplètement ce qui conduit à une architecture qui n’est plus centrale au projet mais qui le gangrène. Les projets de basse intensité, de prototypage ou ceux pour lesquels n’intervient aucune ressource spécialiste de SOA risquent moins à appliquer un style REST simple ou N-tier et à y coller, plutôt que de vouloir « faire » de la mauvaise SOA.