Il existe un proverbe qui dit qu’un bon conseiller doit connaître ses proverbes. Derrière un proverbe il y a toujours une situation humaine récurrente, ce que nous avons décidé de désigner par pattern. Caractéristiques récurrentes de nos SI, la portée d’un pattern s’étend de l’organisation, au fonctionnel et au technique. Ils correspondent à des solutions élégantes ou au contraire inadaptées – on parlera d’anti-pattern - face à des situations répétées : s’organiser en équipe projet intégrée et cadencée en itérations courtes (pattern Agile), bâtir un système décisionnel ouvert sur un référentiel multi-pyramide, enrichir dynamiquement une interface Web par des données (pattern Ajax), sont autant de concentrés d’expériences vécues et capitalisables.

Rome ne s’est pas faite en un jour dit le proverbe.

Comment s’est faite Rome d’ailleurs ? Un grand monsieur est venu avec un plan détaillé des rues, des égouts, des parcs, des maisons, des immeubles et des lieus publics, on a téléphoné à Accenture, et ils ont construit Rome. Non bien sûr. Sinon Rome ressemblerait à DisneyLand.

Au lieu de cela, Rome s’est construit sur des récurrences qui ont imprégné les différents incréments – dont certains destructifs - qu’a subi la ville : un fleuve, un bois, une pierre particuliers, des toits, des palais, des champs, des ponts, des bouts d’égouts, des canons, pas de métro, …

Dans les SI de gestion, ceux qui automatisent des portions de processus humains, la complexité ne s’apprivoise pas avec un bazooka. Cette tentative de l’aborder d’avance est prétentieuse puisque nos processus sont par essence flous, imparfaits et évolutifs avec le temps. Quand elle ne conduit pas à l’échec pur et simple, la démarche en cascade produit du logiciel lourd, déstructuré et donc difficilement maintenable.

Autant la métaphore du BTP est inutile pour décrire la construction de Systèmes d’Information, autant celle de la littérature nous aidera à mieux exprimer la réalité de nos métiers. Un livre peut s’écrire de deux manières : chapitre par chapitre, puis une dernière passe pour corriger et raccorder l’ensemble, ou bien dans sa globalité à un niveau général, puis rédaction des chapitres dans un ordre quelconque. Il est des livres dont on perçoit l’architecture, d’autres non. Les premiers vous marquent, c’est le cas par exemple chez Kundera, grand écrivain situationniste, dont la prose n’est pas logorrhée informe, mais structure mettant en scène des personnages pour mieux exprimer une situation qui se reproduira, un pattern : l’insoutenable légèreté de l’être, l’impossible retour d’exil, …

Ainsi se résume l’essence de l’approche incrémentale. L’appliquer au logiciel signifie être capable de se lancer dans le code en acceptant de ne pas avoir écrit son histoire dans le détail, mais seulement dans son ensemble. Pour cela, il faut maîtriser la peur du brouillard. Car le réflexe de la cascade (cahier des charges complet, spécifications détaillées complètes, ..) révèle la volonté de diminuer cette peur en chassant le brouillard. Pourtant cette stagnation sur l’écrit contribue à l’effet inverse, elle augmente la peur en faisant enfler dans le détail un objet que souvent plus personne ne peut comprendre dans son ensemble.

A l’opposé, la culture incrémentale propose de réaliser le logiciel par incrément, c'est-à-dire en résolvant rapidement une situation simple, mais de bout en bout. Puis une deuxième situation qui le complexifiera, et ainsi de suite. A chaque itération, le logiciel propose des fonctionnalités intègres, qui nous permettront de mettre en situation un utilisateur et récolter régulièrement son feedback.

Cette approche ne peut se concrétiser que dans un environnement où le contrat fait place à la confiance, où l’on pense partenaire quand on parle de fournisseur, dans la même logique que nos confrères industriels et leur principe reconnu du Keiretsu, intégration d’entreprises autour d’un objectif commun, d’intérêt partagés qui se déroulent sous une direction commune.