Vos mauvais choix techniques plombent vos chances de succès

La technique n'est pas LA solution pour réussir tous ses projets informatiques, mais c'est se retirer une belle épine du pied que de prendre le temps d’effectuer de bons choix techniques. Mais comment faire ? Qu'est-ce que cela implique concrètement ? Voici huit préconisations pour vous aider au quotidien.

Aucune entreprise de BTP en 2011, aurait idée de construire un building en utilisant uniquement des truelles et des brouettes. De même, aucun chirurgien ne commettrait l'incurie d'opérer ses patients en utilisant exclusivement des gants Mappa et son couteau de cuisine. Et personne n'aurait idée d'utiliser un 38 tonnes, pour aller faire ses courses de la semaine.
Comme vous le savez, pour chaque activité, il existe un outil qui offre une efficacité optimale pour parvenir à ses fins, ne pas l'utiliser, c'est aller au devant de quelques déconvenues.
Bien que mon propos, plein de bon sens, puisse jusqu'à présent être interprété comme un ramassis de trivialités, je tiens à souligner que cette piqûre de rappel soignerait bien des maux dans notre secteur. Il semble en effet, que la technique y joue (consciemment ou inconsciemment) le rôle de cinquième roue du carrosse. Étonnant pour un secteur qui a tiré l'essentiel de sa croissance grâce aux avancées technologiques. Certes, la technique ne fait pas tout dans un projet informatique, mais elle garde néanmoins une importance capitale.
DSI, managers, développeurs, et tout ceux qui œuvrent dans le secteur informatique, sachez que de mauvais choix techniques mènent tôt ou tard à l'échec (les dettes techniques finissent toujours par êtres payés), que des choix techniques non optimaux vous handicaperont face à vos concurrents.
Un projet qui a été mal ficelé techniquement est un projet plus risqué, plus coûteux, qui a de fortes chances d'accoucher d'un produit caduque de mauvaise qualité qui ne sera pas livré dans les temps.
Et cela, c'est dans le cas où vous avez décroché le projet, parce que de mauvais choix techniques peuvent vous pousser à chiffrer votre projet à la hausse par rapport à vos concurrents, et donc facturer plus cher votre prestation (pour une qualité comparable) et donc de perdre un marché ou un appel d'offre.
Alors non, la technique n'est pas LA solution pour réussir tous ses projets informatiques, mais c'est se retirer une belle épine du pied que de prendre le temps d’effectuer de bons choix techniques.

Mais au fait, pourquoi fait-on de mauvais choix techniques ?
- Parce que l'on se fiche éperdument de la technique.
- Parce que l'on n'y connaît rien en technique.
- Parce qu'il nous manque des informations (enjeux, tenants et aboutissants, contexte etc...) sur le projet.
- Parce que l'on est borné et qu'on ne revient jamais sur ses mauvaises décisions.
- Parce que l'on est pas au courant des nouveautés dans le domaine des (bonnes) pratiques, frameworks, langages de programmation etc...
- Parce que le client a des contraintes qui le pousse à nous forcer de faire des mauvais choix techniques et qu'on ne sait pas lui dire non.
A l'instar de ce célèbre constructeur automobile allemand, je prône donc l'avance par la technologie. Mon propos, vous a peut-être (je l'espère !) sensibilisé sur l'importance des choix techniques, mais vous vous demandez probablement comment faire de bons choix techniques. Vous vous demandez ce que cela implique concrètement.

C'est justement l'objet de la suite de cette chronique, âmes sensibles, s'abstenir...
Je vais détailler les huit préconisations qui vous aideront au quotidien:
* Ne réinventez pas la roue
* Ne faites pas de choix techniques obsolètes
* Choisissez les bons outils
* Protégez vous des intégristes
* Apprenez à revenir sur vos décisions lorsque c'est nécessaire
* Apprenez à dire non à votre client
* Gérez correctement votre budget licence
* Entourez vous d'une équipe de développeurs compétents techniquement

I - Ne réinventez pas la roue
Il est inutile et coûteux de faire soit même ce qui peut être fait correctement par des outils tiers.
Par exemple, il est de nos jours inutile de gérer manuellement la persistance des objets, des frameworks le font pour vous (hibernate, toplink, mybatis etc...). De même, il est parfaitement inutile sur un projet Java, de gérer vous même les dépendances entre les librairies que vous utilisez, Maven le fait très bien. En fait, chaque fois que vous avez une action à entreprendre ou autre, prenez le temps de chercher s'il n'existe pas un outil qui permet de le faire.

II – Ne faites pas de choix techniques obsolètes
De grâce, évitez dans la mesure du possible de faire des choix d'outils ou de standards obsolètes. J'ai vu des projets où l'on utilisait le standard JPA1, alors que la deuxième version était disponible depuis des mois... Il faut impérativement privilégier les dernières versions stables des outils que vous utilisez, il ne s'agit pas de jouer les bêta testeurs des outils que vous utilisez, mais plutôt de bénéficier des derniers correctifs et de pouvoir utiliser des nouvelles fonctionnalités qui permettront à votre équipe de fournir un travail de meilleure qualité avec une productivité accrue. Ainsi, ceux qui ont snobé par mégarde JPA 2, n'ont pas bénéficié des criterias fortement typés et ont donc perdus des jours et des jours à faire ce qu'une implémentation de JPA 2 pouvait faire à leur place.

Plus pervers, j'ai connu un projet qui a débuté au début des années 2000, et dont l'équipe avait misé sur l' ASP. En 2003 lors de la mise en production du logiciel, ASP était obsolète depuis un an (depuis l'arrivé de .NET en fait). Depuis, l'équipe de développement paye le prix élevé de ce mauvais choix technique. La morale de cette histoire, est qu'il ne faut pas se contenter de faire des choix qui sont pertinents au moment où on les fait, mais il faut être suffisamment visionnaire et en phase avec l'actualité, pour s'assurer qu'ils le resteront à l'avenir. La pérennité des outils que l'on choisi (le fait qu'ils soient régulièrement mis à jour et supportés par leurs fabricants) est donc très important.

III- Choisissez les bons outils
Vous avez besoin de faire une interface graphique en AJAX, afin d'offrir au client une expérience utilisateur attrayante. Devant supporter le maximum de plate-formes, vous avez bien évidemment écarté Flex et Silverlight. Étant au fait de l'actualité, vous avez entendu de parler JQuery, la fameuse librairie, qui simplifie le développement Javascript. A supposer que JQuery soit parmi toutes les librairies Javascript, la plus adaptée à votre projet, elle est, et reste qu'une librairie Javascript. J’entends par là, qu'elle ne vous protégera pas des inconvénients intrinsèques au langage (typage faible etc..).
En optant pour des frameworks comme GWT, vous êtes certes dépendants de la plate-forme Java, mais vous vous affranchissez des contraintes inhérentes à Javascript, vous bénéficiez de toute la puissance d'un langage fortement typé et (vraiment) orienté objet. Vous facilitez le partage de code entre la partie cliente et la partie serveur de votre application. La conception IHM, si coûteuse d'ordinaire s'en trouve accéléré, fiabilisé (grâce au typage fort et aux outils de débogage) et simplifié (un stagiaire de cinquième année pourrait s'en charger sans trop de soucis). Finalement, est-ce si gênant de dépendre de Java ? A vous donc de peser le pour et le contre.
Autre cas, vous avez choisi de développer un client lourd qui est voué à communiquer avec un ensemble de services WCF (Windows Communication Foundation), certes WCF est compatible avec SOAP, vous êtes donc libre de choisir le langage de votre choix pour le client lourd, ça c'est la théorie. Dans la pratique, il sera beaucoup plus facile de communiquer avec WCF si le client prend nativement en charge WCF, cela implique qu'il soit codé en .NET. Cela a bien évidemment des conséquences néfastes sur la portabilité et les performances de votre application, mais le développement de tout ce qui permet au client lourd d’interagir avec les services en sera grandement simplifié. A-t-on réellement besoin de performances optimales et de portabilité ? Là encore, à vous de peser le pour et le contre.
Lors du choix d'un outil, observez tous les cas d'utilisations de cet outil, n'hésitez pas à le tester sur des exemples réalistes.

IV - Protégez vous des intégristes
Vous faites partie d'une équipe de développement qui est amené à faire collégialement des choix techniques en fonction de diverses informations (cahier des charges etc...) qui vous ont étés fourni.
Vous n'aurez aucun mal à reconnaître ces nuisibles que sont les intégristes. L'équipe n'aura pas fini de lire les contraintes et les exigences du client (ou pire n'aura même pas commencé) que les intégristes auront déjà affirmé leurs choix haut et fort et l'imposeront au reste de l'équipe. Ces mêmes intégristes, à défaut de trouver des justifications, fourniront des explications vaseuses du genre : «On le fait en .NET !! Pourquoi ? Parce que j'adore .NET et que Java c'est de la merde !! » ou « Bah on va le faire en Ruby ! Pourquoi ? Bah ça à l'air sympa et puis c'est la techno qui monte qui monte !! ».
Je préfère être clair et net, si je qualifie les intégristes de nuisibles, c'est parce qu'ils vous poussent à bâcler vos choix techniques. Parce qu'ils imposent (en utilisant parfois l'intimidation) leurs choix sans justification (explication objective) et se fichent éperdument de ce qu'en pensent les autres et des conséquences que ça peut avoir sur le projet. Leur façon de procéder met donc en péril le projet et la cohésion de l'équipe. A supposer que de tels individus, fermés sur eux mêmes, aient leurs places dans une équipe de développement, leurs intégrisme est prié de reposer en paix. Faute de quoi, il faudra leur faire face, supporter la pression qu'ils vous infligent et bien évidemment n'accorder aucun crédit à leurs affirmations.

V- Apprenez à revenir sur vos décisions lorsque c'est nécessaire
Personne n'est parfait, il nous arrive tous de faire des erreurs, l'important est de (comme le préconisent les méthodes agiles) s'en rendre compte, de corriger et de voir ce qui peut être fait pour que cela ne se reproduise plus.
Il semble toutefois, que mon propos soit plus facile à écrire qu'a mettre en application. Entre les développeurs, architectes, qui n'ont pas le recul et les compétences nécessaires pour se rendre compte de leurs erreurs, ceux dont l’ego démesuré empêchent de reconnaître publiquement leurs erreurs, et ceux qui malgré leur lucidité et leur bonne volonté n'ont pas le temps de mettre sur pied, les actions préventives pour éviter de réitérer les erreurs, il ne reste plus grand monde capable de réellement revenir sur ses choix.
Les gens incapables (de par leurs manque de recul ou de compétences) de reconnaître leurs fautes, doivent bien évidemment êtres aidés, voir remplacés dans les cas les plus graves.
Les individus aux egos surdimensionnés n'ont pas plus leurs places dans une équipe que les intégristes.
Pour ceux dont le temps manque, il faut probablement tenir compte des actions préventives dans les chiffrages du projet, ce qui n'est hélas, pas chose facile.
Je rajouterais qu'il faut lorsque l'on fait des choix techniques, qu'ils soient assez souples, pour que les corrections ultérieures soient les plus rapides possibles. Les frameworks web multi-navigateurs, les ORM multi-bases , les standards, la séparation des couches d'une application etc... Sont autant d'outils et de mesures qui vont dans ce sens. Il faut donc observer les choix techniques qui ont le moins de chances d'êtres pertinents et de les mettre en œuvre de façon à pouvoir les changer le plus facilement possible, ce qui paradoxalement n'est pas chose aisée.

VI- Apprenez à dire non à votre client
Le client a sa vie, ses problèmes, ses préoccupations, sa vision de l'informatique. Ce tout l’emmène à définir des exigences dans le cahier des charges qui limitent le champ des choix techniques. Il y a des fois où ces limitations sont pertinentes et des fois où elles échappent à la raison. Pour vous donner une idée plus concrète de mon propos, j'ai eu l'occasion de travailler sur un projet qui certes, partait de zéro en terme de développement, mais où le client voulait qu'on lui fournisse un code qu'il soit capable de maintenir, il a donc fait une multitude de choix techniques assez restrictifs. Comme par exemple, l'obligation de développer en Java (et si .NET était plus adapté?), de mettre de la Javadoc partout (donc même là où ce n'est pas nécessaire...) et surtout l'interdiction d'utiliser Maven.
Encore une fois, il convient d'être clair : chacun son métier. Si le client connaît probablement mieux les problèmes fonctionnels auxquels il est confronté, nous connaissons certainement mieux que lui les moyens techniques de les surmonter, sinon pourquoi aurait-il besoin de nous ? Sommes nous uniquement de la main d’œuvre qui produit des prestations de faible valeur ajouté ?
Les choix techniques que font les clients ne sont pas toujours pertinents et ont tendances à saler l'addition qu'il devra régler, c'est donc aussi dans sont intérêt de laisser aux développeurs le plus de liberté possible dans les choix techniques. Il faut donc discuter avec le client de la pertinence de chaque contrainte technique qu'il nous impose, et lorsque non pertinence il y a, bien lui faire constater ce que cela lui coûte et le peu que cela lui rapporte. Cela nécessite la capacité de pouvoir dire non au client, de pouvoir le convaincre, bref d'avoir des capacités de relation client qui semblent faire défaut à pas mal de gens qui sont pourtant en contact direct avec le client. Attention, je ne dis pas que c'est toujours chose aisée, mais qu'il faut au moins se donner la peine d'essayer. Souvent, on est confronté à des clients qui ont un parc informatique sous Internet Explorer 6, bien évidemment le développement sous des navigateurs obsolètes est plus coûteux et moins pérenne que sur des navigateurs récents. Pourquoi ne pas accompagner le client dans la migration de son parc informatique, plutôt que de laisser se débrouiller tout seul pour prendre en charge les contraintes techniques que nous lui suggérons ? En l'accompagnant, il y a plus de chance qu'il accepte notre requête.

VII- Gérez correctement votre budget licence
On trouve de tout, des entreprises qui ne veulent pas lâcher le moindre centime en achat de licence à celles qui dépensent sans compter. Pourtant, ces deux extrêmes ont bien souvent un point commun, ils veulent réduire les coûts de productions de leurs logiciels ou systèmes d'informations. Il convient donc de trouver un juste milieu. Il faut comparer le coût des licences aux coûts de développement, une licence à 150€ sur un projet qui en coûte 30000€ a un coût négligeable. Il faut ensuite voir ce que le logiciel nous apporte réellement, déterminer (à la louche) le nombre de jours de développement qu'il nous fait économiser, et en déduire s'il est rentable ou pas. Cette façon de procéder pourra peut-être permettre à certains de convaincre leur hiérarchie d'acheter certaines licences.
A contrario, il est inutile d'acheter un logiciel s'il ne nous fait pas économiser des jours de développement ou si il ne permet pas d'améliorer la qualité de nos productions. Je suis personnellement las de voir toutes ces entreprises qui sur des petits projets, payent d’onéreuses licences pour acquérir des bases de données d'une célèbre firme californienne, alors que des alternatives open sources auraient largement fait l'affaire. Autant d'argent gaspillé qui ne pourra être réutilisé là où on en a vraiment besoin... Ou encore ces boites, qui payent des environnements de développement intégrés hors de prix, là ou une version gratuite et récente d' Eclipse aurait fait mieux.
Là encore, la clarté est de rigueur, la qualité des produits qu'on achète n'est pas toujours proportionnelle au prix que l'on paye, afin de ne pas êtres les dindons de la farce, il faut analyser tous les concurrents présent et ne pas hésiter, plusieurs mois (ou années) après que l'achat a été fait, de voir si l'outil est toujours compétitif et de le remplacer dans le cas échéant.

VIII- Entourez vous d'une équipe de développeurs compétents techniquement
C'est bien beau de faire des choix techniques novateurs, mais si l'équipe n'est pas capable de les mettre en application, c'est plus qu'inutile, c'est contre productif.
Dans le cas plus raisonnable où c'est l'équipe de développement qui fait les choix techniques, elle est certes capable de les mettre en œuvre, mais ces choix, sont-ils optimaux ?
Dans tous les cas, une équipe dont les compétences techniques laissent à désirer, n'aura pas une productivité optimale. Et ces équipes sont beaucoup plus nombreuses qu'on le croit.
Je ne connais pas beaucoup de développeurs qui savent ce qu'est un paradigme de programmation. Je ne connais des gens qui prétendent aimer .NET, êtres spécialisés là dedans, mais qui ne connaissent pas tous les frameworks phares de cette plate-forme. Je connais des tas de développeurs qui n'ont pas de diplôme d'informatique, mais juste une formation scientifique de niveaux bac + 5 ... Je connais des tas de développeurs, pourtant sorti de prestigieuses écoles d'ingénieur (dont je met désormais en doute la qualité de la formation et donc le mérite de leurs prestige), pourtant expérimentés, qui n'ont aucune notion d'architecture logicielle, qui ne sont pas à l'aise avec la programmation orienté objet, et qui n'ont jamais entendu parlé de programmation orienté aspect. Sincèrement, comment voulez-vous que des équipes constituées de tels individus fassent des choix optimaux ?

Comment ne pas être confronté à de telles équipes ?
Comme on dit, vrais reconnaissent vrais, donc il faut que quelqu'un de calé techniquement se charge des recrutements et évalue sérieusement et objectivement les compétences du candidat. En effet, le meilleur moyen pour que les mauvais techniciens ne se retrouvent pas dans votre projet, est qu'il ne se retrouvent pas dans votre entreprise. Il faudra aussi que cette personne décide de qui est apte ou pas à rejoindre tel ou tel projet. Au risque d'être un brin provocateur, ce n'est pas en faisant passer des tests psychotechniques (comme ceux qu'ont eu à passer les aides-soignantes et les infirmières) à vos futurs employés, que vous pourrez vous assurez de leurs compétences techniques en informatique. Il faut un réel entretien, pourquoi pas des tests écris. Ne vous fiez pas aux diplômes, ce ne sont que de piètres indicateurs, ne vous fiez plus aux certifications, ne vous fiez pas non plus à l’expérience (toutes les expériences ne se valent pas) présente sur le CV, elles sont souvent exagérés, ne vous fiez pas à votre instinct, mais juste à votre objectivité.

Comment faire lorsque l'on est malgré tout confronté à de telles équipes ?
Si vous n'avez personne de compétent techniquement sous la main, il faudra faire avec dans un premier temps et faire le maximum par la suite pour ne pas vous retrouver dans cette situation.
Dans le cas où vous disposez de quelqu'un de calé techniquement, il faudra qu'il fasse partie de l'équipe et qu'il la forme. Paris ne s'est pas faite en un jour, et il y a des notions techniques qui sont très difficiles à appréhender, donc cette monté en compétence prendra du temps, pas mal de temps. L'équipe ne sera pas efficace à 100% au début, mais au fil des mois, voire des années, elle finira par acquérir les compétences techniques que l'on est en droit d'attendre d'elle.
Vous vous rendez compte maintenant de la difficulté de réunir toutes les conditions nécessaires pour faire les bons choix, si importants pour la réussite de votre projet sur le court, moyen, et long terme. A vous, quelque soit votre fonction, de faire valoir l'importance des choix techniques dans votre organisation, et d'éviter ainsi un nivellement par le bas de l'informatique.