Le "Projet Flexible" : la fin des grands projets SI risqués

On sait depuis longtemps que les risques d'échec des projets informatiques sont importants. On sait que ces risques s'accroissent en fonction de la taille du projet.
Voir à ce sujet l'excellent article de Frédéric Charles sur Pulse.

Dessin de FIX expert en projets

Et pourtant on continue de mener des projets complexes.
Certes les entreprises et organisations évitent les grands projets. Elles privilégient des développements agiles, et incrémentaux. Cela suffit-il pour créer, au fil du temps, un patrimoine SI harmonieux ? L'obsolescence existera toujours, et, combinée aux exigences des nouveaux espaces qui attirent le business, des projets d'envergure demeurent incontournables.

Une approche traditionnelle rationnelle mais risquée

Il est temps d'envisager de mener ces projets complexes selon une approche différente. La complexité ne se réduira pas d'elle même, Dans un récent article paru dans la revue Génie Logiciel (N° 117 juin 2016), j'ai proposé une explication de cette complexification "naturelle".

On pourrait penser que les développements agiles, que l'abandon du cycle en cascade, que DevOps, sont le remède pour maîtriser les aléas des projets, et réduire la sinistralité. Certes, mais les erreurs, les surprises, ne se situent pas seulement dans le codage, qui est de l'ordre du détail, mais dans l'Architecture du SI. Elles impactent l'assemblage de grands ensembles de codes et de données, avec des effets imprévus perturbants, parfois catastrophiques.

L'approche traditionnelle définit cette architecture qui fonde les développements à engager. Le projet SI en découle, avec ses contraintes de dépendance et ses phases d'intégration, ses tests.

C'est l'ambition de prévoir la décomposition en sous-ensembles fonctionnels, les fameux "building blocks", optimale, calquée sur un puzzle fonctionnel qui sert de maître à penser.

La gestion de projet répartit, ordonnance les travaux et ressources ... en se basant sur cette conception immuable. Une parfaite ingénierie, fondée sur un jeu d'hypothèses objectives : évolution du Business, contraintes réglementaires, bases technologiques, organisation du travail, processus, engagement client, ...

Comment, avec une telle ambition de tout prévoir et ordonnancer, ne pas se tromper ? Il est naturel qu'il y ait des changements, et les aléas sont inévitables. En somme, s'engager dans un projet, c'est entrer dans un labyrinthe dont on croit avoir le plan. Mais, en chemin, les faits se vengent, bousculent le plan, les impasses se révèlent.

Ces changements sont d'autant plus perturbants que le projet est complexe. La combinatoire entre les multiples imprévues est infinie. Tout au plus pourrait-on mettre en équation les probabilités composées qui expliquent les risques pris dans l'architecture traditionnelle de grand projet.

Le projet flexible : refonder l'approche des projets complexes

Les risques projet majeurs sont imputables aux risques portés par l'architecture et par les intégrations induites. Ils ne sont pas localisés en un seul composant, mais dans la propagation systémique, allant jusqu'aux fatals effets domino.

L'architecture traditionnelle repose sur les intégrations donnant assez peu de degrés de liberté. Certes l'intégration par API est plus souple. Elle ne réduit pas la complexité, qui se cache encore sous cet habit de modernité. Le syndrome du "plat de spaghetti", version API, menace.

L'architecture flexible fait éclater ce modèle, et systématise la flexibilité des intégrations. Elle constitue une épine dorsale fondée sur les invariants des chaînes de valeur, naturellement "anti-sismique". Les combinaisons peuvent être testées dès que le cas se présente, à temps pour prévenir les incidents, et avant toute décision sans retour dans un cycle de développement, fût-il agile, dans une conduite du changement, dans un plan de communication.

Ceci a 3 conséquences :

• réduire les aléas, car les "joints de dilatation" mis en place encaissent de nombreuses surprises, l'architecture n'en est pas remise en cause, et il n'y a pas de propagation systémique
• simplifier les dépendances entre travaux de développement de logiciel, ceux-ci pouvant être parallélisés ou différés en fonction des urgences ou opportunités,
• prolonger la durée de vie des applications actuelles, qui peuvent être connectées aux nouveaux composants, sans intrusion, rapidement et à peu de frais. Réduisant d'autant la taille du projet.

C'est une approche en rupture avec la tradition. Nous l'appellerons l'approche "projet flexible". Profitant de l'architecture flexible, le projet pourra différer des choix, éviter de les figer a priori, de spécifier, s'adaptant ainsi, au fil de l'eau, aux évolutions apparues, ou incidents constatés.

Engageant en amont les POC de démonstration et de validation, le projet flexible crée la plateforme de base, le "Data Hub", avant les travaux lourds de développement, de conduite du changement. Le projet flexible complète ainsi les nouvelles approches, agiles, ou DevOps, qui ne portent pas sur le plan de l'Architecture. Agnostique par rapport aux choix technologiques, le projet s'adaptera à tous les contextes techniques.

Changement de paradigme projet

Belle promesse diront les sceptiques. Oui, mais sous condition ! En effet, tout l'avantage découle du "Data Hub" qui est au cœur de l'architecture flexible.

La conception du Data Hub est l'équivalent de la conception de l'architecture dont il était question ci-dessus. La nuance est que cette architecture devient concrète, préexistante, testée, démontrée, au point qu'elle valide ses bases architecturales, sur toutes les "couches" habituelles, du Business, au métier, aux processus, aux SI.

C'est un changement de paradigme projet :

• l'intégration devient le premier travail, avant les développements,
• l'ordonnancement projet est moins piloté par les pré-requis SI, et les dépendances entre composants SI, et prend en compte d'autres rigidités,
• les choix de solutions alternatives, au niveau SI, sont ouverts.

Un projet global calé sur les facteurs sociaux et humains

Les contraintes dues au SI étant diminuées, le projet est plus fluide, avec la possibilité de produire des résultats plus facilement, plus rapidement, de façon diversifiée et plus fiable. En somme, l'inertie de la composante SI du projet est réduite.

Cependant le projet comprend en général d'autres composantes : processus, métier, façade client, industrie, logistique. Le changement de chaque composante  a ses caractéristiques propres, son inertie, son temps de cycle.

L’allègement de l'inertie SI permet de repenser le projet global, en le calant sur les facteurs sociaux et humains, sur les contraintes industrielles. La flexibilité permet aussi d'éclater le projet global en autant de sous-projets qu'il y a de segments clients, ou de zones géographiques, ou toute autre classification pertinente pour constituer des variantes adaptées au contexte.

La flexibilité de l'Architecture ouvre une perspective enthousiasmante de flexibilité du projet, pour minimiser les risques techniques et sociaux, et maximiser l'acceptation et le retour sur investissement au plus tôt.

Le projet flexible : la fin des projets tunnel, des mega-projets d'intégration, des grands projets voués à l'échec et dont on n'ose parler.