Les raisons sont aussi nombreuses qu’il y a de contextes opérationnels. En premier, le manque chronique (structurel ?) d’agilité de la direction informatique dans sa capacité à répondre dans les délais, dans les budgets et dans le périmètre fonctionnel. A leur corps défendant rappelons qu’au-delà de la maitrise (réduction ?) des coûts qui leur sont légitimement imposées, les DSI sont un service mutualisé devant répondre à des organisations internes diverses dont les demandes sont, par essence, plus nombreuses que la capacité à traiter, qui ne peut être infinie. Ce faisant, les hommes métier multiplient les initiatives avec des outils adhoc afin de gagner en flexibilité.

• Prendre en compte les contraintes d’agilité ou de time-to-market des Business Units

Qui n’a pas développé - ce qui au départ n’était qu’une simulation dans une feuille de tableur - une « application » qui à force de sophistications itératives (à base de formules de calculs et/ou de macros par exemple) en est venue à gérer des propositions commerciales sur des projets client à plusieurs zéros ou une chaine de production ? Les exemples sont infinis...

Tout va pour le mieux dans le meilleur des mondes jusqu’au jour où une évolution du système d’exploitation ou de l’outil bureautique sous-jacent rend l’application instable voir non-fonctionnelle ; jusqu’au jour, où l’utilisateur-concepteur n’est plus seul et souhaite échanger, collaborer avec un pair rendant la réconciliation des évolutions tant au niveau des données que du traitement fort complexe ou fort longue. Bref la productivité et la stabilité de l’ouvrage s’en trouvent affectées. Vient alors l’heure de demander à la direction informatique et à ses spécialistes de reprendre la main.

Seulement voilà, il n’existe aucune documentation susceptible d’expliquer ce que fait vraiment l’application. Et quand bien même toutes les règles métier seraient-elles compréhensibles par le développeur en charge de ce travail, il les implémentera dorénavant… avec les technologies « officielles », inaccessibles aux hommes du métier. La rupture est consommée. Adieu alors contrôle du métier sur ses évolutions futures pourtant essentielles à la satisfaction des objectifs professionnels. Nous voilà revenu au point de départ, aux raisons ontologiques de l’existence de cette application !

Cette pratique est aujourd’hui reconnue (tolérée ?) par le Cigref qui écrit dans son analyse prospective des coûts informatique : « Les Business Units expriment aussi de plus en plus d’attentes en termes de solutions plus légères, agiles et pragmatiques. [..] Les Business Units ont tendance à pousser à la ré-intégration au sein de la DSI de tous les « petits développements » qu’elles auraient réalisés à leur niveau de façon à en sécuriser la maintenance et les évolutions.»

• MyDraft, une rupture SaaS dans la zone grise du développement d'entreprise

MyDraft a été conçu dans l’optique de mettre, dans les mains des hommes métier, un outil, simple parce que ne requérant aucune compétence informatique préalable, collaboratif parce que facilitant la coopération entre pairs et agile parce que autorisant les itérations, les scénarisations, les retours dans le temps grâce à son moteur de traçabilité intégré. Avec MyDraft, les directions fonctionnelles ont une solution « pérennisable » afin de satisfaire leurs besoins en applications agiles que la DSI ne peut traiter, toute attachée qu’elle est à faire fonctionner les services en place et à piloter les grands chantiers structurant à venir.

Les bénéfices de nos solutions pour les experts métier sont nombreux. La proposition de valeur est solidement structurée par les 4 actes fondateurs suivants :

• Exprimer sa vision
• Collaborer en confiance
• Mener l'innovation
• Déployer en continu