22 May 2013, 22:05

Du bon usage du 'non'

Lors d'un projet informatique se pose toujours la question de l'adéquation entre les besoins couverts par la solution (raisons pour laquelle elle a été retenue) et le relicat de besoins non couverts nativement. Avec la question : fait-on ses développements spécifiques ?

Si à court terme, ces besoins "spécifiques" peuvent être légitimes pour de plus ou moins bonnes raisons (chez nous, on fait comme ci comme ça ; on a *absolument* besoin de la fonctionnalité X pour faire Y ; ils sont trop nuls l'éditeur Z, ils n'ont pas prévu la fonctionnalité W, etc) ; on se pose moins la question à long terme : en faisant du spécifique, est-ce que j'accepte de payer X € pour reconduire mon spécifique d'une version sur l'autre ; dès lors, on se construit soit même une sorte de *dette technique* vis à vis du projet.

Pire, sur un projet sur lequel je travaille et basé sur une solution propriétaire, le responsable de la branche "Services" et l'équipe avant vente nous avaient pourtant mis en garde sur trop de spécifique et au contraire, nous avaient conseillé de suivre tout un tas de bonnes pratiques afin de pouvoir suivre facilement les montées de version du produit. Cela me parut étrange vu qu'après tout, il devrait être intéressé à "encourager" le client à faire des intégrations vu qu'au final cela lui permettrait de vendre plus de prestations... Si même l'éditeur ne pousse pas à la consommation, pourquoi le ferions nous à tout prix ?

Dès lors, quelques questionnements sur ce sujet :

  • Pour une DSI et/ou SSII, réaliser des développements spécifiques, c'est s'assurer son fond de commerce dans une certaine mesure. Pour autant, il ne faut pas que le spécifique ait un cout financier ou technique qui devienne trop prohibitif ?
  • Vouloir satisfaire son client à 100%, est-ce vraiment l'objectif à atteindre ? Jusqu'où est-il raisonnable techniquement & financièrement d'adapter (tordre ?) la solution pour répondre à tel ou tel besoin ?
  • Le discours sur les solutions Open Source qui consiste à dire que l'on peut toujours adapter la solution X à vos besoins ne fait-il pas au final plus de mal que de bien ? Il s'est certes construit en opposition à une logique éditeur où en exagérant les besoins s'adaptent à l'outil et non le contraire. Les solutions open source n'ont certes pas de frais de licences (quoique avec le support...) mais au final, les développements spécifiques ne remplacent-ils pas ces frais de licences et construisent ce "lock-in" ? J'écarte d'emblée aussi le discours du "on reversera la fonctionnalité Y dans la communauté qui le prendra alors à sa charge, soyez-en assuré !"
  • Avec l'explosion des solutions SaaS où les personnalisations sont par essence minimes, voir inexistantes, comment font les métiers pour passer sur ce spécifique manquant ?
  • Pourquoi les métiers sont parfois frileux à l'idée de tester les fonctionnalités natives de l'outil et une fois expérimenté en conditions réelles pendant un certain temps procéder au développement si le besoin est réellement là ? Peur de ne plus avoir de budget pour faire faire ces travaux ?
  • A faire trop de spécifique, on perd en agilité ; projet de migration plus complexe et couteux ; à ce niveau, est-ce que le développement spécifique justifie de ne suivre les évolutions du produit retenu que toutes les n versions et se priver des apports des versions ultérieures entre 2 chantiers de migration ?
  • Est-ce une pratique particulièrement française (voir latine) vs un pragmatisme anglo-saxon ?

Au final, reste que dire non de façon justifiée et raisonnable aux directions métiers quant à l'expression de leurs besoins, ce n'est pas par méchanceté ou que sais-je mais cela demande un peu de pédagogie pour montrer les intérêts sur le long terme et que "Oui la solution n'est pas parfaite mais elle couvre l'essentiel de notre besoin". A vouloir trop, on a rien ou peu et surtout dans des contextes budgétaires serrés. Reste aussi la question "Ce serait votre budget, est-ce que vous dépenseriez réellement ce montant pour ce projet ?". Quand je vois le coût de certaines spécificités, personnellement, non...