Styles

jeudi 28 août 2008

La lecture plaisante de code source, ou comment éviter de perdre son temps

Vous n'avez pas l'impression que l'informatique tourne en rond en ce moment, qu'elle ne cherche plus à innover mais simplement à recréer ce qu'elle a déjà oublié ?

Pourquoi recréer le client lourd dans le navigateur Web quand justement, on n'était sorti du client lourd sous Windows ? Pourquoi tant d'effort déployé par des myriades de passionnés d'informatique pour produire des outils permettant uniquement de créer d'autres outils, etc ?

Quand on voit le nombre de frameworks redondants, d'applications Web reproduites à l'identique en des milliers d'exemplaires différents mais pourtant bien semblables tel que les CMS... on peut se demander d'où vient le problème.

A mon avis, c'est que le développeur de base, chez lui, le passionné d'informatique s'imagine capable de créer un monde à son image quand il se met à développer un nouveau logiciel "from scratch".

Le problème c'est que quand il décide de partir de zéro pour créer un nouveau logiciel, dans 90% des cas, son effort est négatif pour la communauté opensource.

En effet, l'effort qu'il pourrait passer à améliorer un logiciel déjà existant, ce passionné le passe à recréer entièrement un logiciel et tout ce qui va avec, toutes les fonctionnalités communes à tous les même type de logiciel, bref à recréer la roue.

Traduction pour le nerd moyen : La création d'une nouvelle itération d'un logiciel déjà existant n'a pour résultat que de diviser l'effort qui pourrait être mis sur une seule itération, sur un seul logiciel.

Développer un nouveau logiciel à partir de rien pourrait sembler intéressant dans un premier temps, mais quand on y pense, cela est vain. A quoi bon recréer toutes les routines de support de l'application alors qu'elles existent déjà sous d'autres formes dans des logiciels similaires ?

Il est pourtant beaucoup plus intéressant d'essayer d'améliorer les logiciels existants. Pour un développeur qui cherche de la reconnaissance par son travail de programmation, la contribution à des projets largement établis sur le Web est beaucoup plus valorisant et instructif que de recommencer dans son coin un bout de code.

La difficulté première, c'est que la plupart des développeurs n'aiment pas lire : que ce soit des livres ou du code source. Or tout est là : c'est dans la capacité à comprendre le code source de logiciels complexes que la productivité d'un développeur peut augmenter.

Lire du code source est extrêmement instructif, il permet de se confronter personnellement à des schémas de pensés contradictoires, à s'immiscer dans la logique profonde d'un autre développeur, voire, plusieurs développeurs.

Au delà du langage de programmation, c'est toute l'intelligence d'un être humain qui apparaît à travers le code source. On peut y voir comment un développeur met en œuvre des outils limités pour obtenir le comportement réellement souhaité.

La lecture du code source est très instructive car elle permet de s'apercevoir que même pour des problèmes en apparence simple, le programmeur doit déployer toute son intelligence pour aboutir à une solution élégante.

L'élégance est affaire de bon goût mais dans le cas de la programmation, chaque développeur y apposera son échelle de valeur. Alors que certains vont chercher l'optimisation à tout prix, d'autres, rechercherons la robustesse, d'autres la maintenabilité, etc. C'est par l'appréciation de toutes ces caractéristiques, qu'un développeur peut sentir l'élégance d'une construction.

dimanche 24 août 2008

Terminologie de la communauté des informaticiens

Je viens de finir de regarder un épisode de "Dr. House". Cette série télé est tellement bien écrite et réalisée qu'elle suscite un désir profond de "faire" de la médecine. Avec tous les termes médicaux qui sont jetés au téléspectateur, la série réussie à flatter notre ego, parce qu'on a l'impression d'y comprendre quelque chose alors que vraiment tout nous échappe.

Cet épisode m'a fait réalisé qu'il nous manquait peut-être quelque chose en informatique, chose que la médecine utilise largement. Il s'agit du nommage scientifique de la moindre petite chose, ou technique. En médecine, j'ai l'impression que l'accumulation du savoir tourne autour du nommage de chaque savoir, une terminologie précise, scientifique, commune à tous les praticiens.

Or quand je lis des livres comme Code Complete ou d'autres, il y a une liste impressionnante de symptômes de mauvais code, de techniques de codage, mais presque aucun nom commun n'est donné pour représenter spécifiquement ces choses. Il serait pourtant vraiment intéressant de pouvoir construire un corpus de noms (un "jargon" ?) pour chaque phénomène, méthode de programmation, style d'écriture de code...

On voit quand même apparaître depuis quelques années un effort dans ce sens avec la volonté de la formalisation de modèles de conceptions ("design patterns") avec des noms spécifiques. Certains informaticiens vont aussi dans cette voie, en essayant justement de définir précisément chaque méthode, fait, causes, en informatique comme Martin Fowler avec son bliki.

Mais, nombre de méthodes, bonnes pratiques, mauvaises pratiques n'ont pas encore de nom propre pour devenir commun à tous les développeurs. Cela ne veut pas dire qu'elles n'existent pas !

L'informatique étant une discipline basée sur la mode du moment, toute référence au passé est suspecte et est considérée comme inutile. On se prive pourtant de nombre de bonnes pratiques, qui malheureusement finissent par être largement ignorées.

Peut-être faudrait-il employer une dénomination à base de racine Grec ou Latine pour provoquer volontairement de la distance avec ces effets de modes. Ça donnerait de la classe aux informaticiens, flatterait aussi leur égo :) Mais en tout cas, cela n'empêchera pas d'avoir de mauvais informaticiens.

jeudi 21 août 2008

Le capital-risque et la levée de fond

Je me suis toujours demandé quel est l'intéret il peut y avoir de créer une startup aujourd'hui, en France. Rêver de devenir le prochain Google ne nourri pas son homme, surtout quand on sait le nombre si faible de Capital investissement en France ou de Business Angels.

Et puis vient un jour un gars nommé Paul Graham qui vous dit que trouver de l'argent c'est très dur (on s'en serait douté :) mais que cet argent n'est pas une fin en soi quand on créé une startup. En effet, dans son article A Fundraising Survival Guide, Paul nous démonte toutes les mauvaises conceptions que l'on a de la levée de fond.

Il part du principe de base que tous les investisseurs sont, à la base, incompétents :
"All investors, including us, are by ordinary standards incompetent. We constantly have to make decisions about things we don't understand, and more often than not we're wrong."
et qu'il ne se feront donc jamais une opinion sur votre société d'après une jugement raisonné :
"the biggest factor in their opinion of you is the opinion of other investors".
Face à un tel décalage entre les aspirations des entrepreneurs et celles des investisseurs, le plus importants message a faire passer c'est que la startup va réussir avec ou sans eux :
"The message (and not just the message, but the fact) should be: we're going to succeed no matter what. Raising more money just lets us do it faster."

"There is nothing investors like more than a startup that seems like it's going to succeed even without them. Investors like it when they can help a startup, but they don't like startups that would die without that help."
Mais ce qui est le plus difficile est d'avoir une idée à la fois bonne et nouvelle ce qui est paradoxal quand on y pense :
"A good startup idea has to be not just good but novel. And to be both good and novel, an idea probably has to seem bad to most people, or someone would already be doing it and it wouldn't be novel."
En France, les gros éditeurs de logiciels ou de solutions fortement basé sur l'informatique sont rares ou se font racheter par des sociétés étrangères.


Face à tant d'obstacles, Paul Graham nous rappelle ce qui est vraiment important quand on décide de se lancer dans l'aventure :
- l'endurance,

- l'adaptabilité,

- la détermination.
Avec ces qualités, on arrivera bien quelque part... peut-être pas vers une réussite pécuniaire, mais en tout cas vers une expérience enrichissante.

lundi 18 août 2008

Programmer dans un langage

David Gries, dans son livre The Science Of Programming (page 235, 18.3.11) énonce un principe plein de sagesse :

Principle : Program into a programming language, not in it.

que l'on peut difficilement (et très librement) traduire en français par :

Principe : Programmer dans un langage, pas pour un langage.

C'est une mauvaise traduction, les mots, "in" et "into" n'étant pas très facile à distinguer.

L'idée est de programmer de façon quasiment abstraite (j'ai dit quasiment, j'ai pas dit complètement :) avec le langage comme simple support du programme. Il faut éviter de programmer pour un langage, c'est à dire, que son programme ne soit structuré par les contraintes et possibilités d'un langage particulier.

David Gries propose de construire son programme et ses structure de données indépendamment du langage utilisé. Cela rejoint un peu la programmation par pensée désirée qui vise à construire un programme en partant d'une vision abstraite et désirée du monde.

Une fois que le programme désiré a été codé, on peut ensuite raffiner les données et le programme pour qu'il "colle" mieux au langage, et ce pour des raisons performance, lisibilité, cohérence avec l'ensemble des librairies à dispositions, etc. Mais ce raffinement ne vient que dans un deuxième temps. Il est nécessaire de ne pas se laisser guider/contraindre par un langage particulier.

On pourrait croire, qu'avec un tel principe, il est nécessaire de savoir coder dans n'importe quel langage. C'est aller un peu vite en besogne, et c'est même l'inverse que je préconiserait. En effet, la véritable maîtrise d'un langage de programmation nécessite plusieurs années d'apprentissage.

Il ne suffit pas de connaître la syntaxe de base du langage. Celle-ci est souvent très simple et peut s'apprendre très rapidement (sauf certains cas significatifs comme Perl qui justement vise à offrir un langage très riche en raccourcis et tournure de phrase). Le plus important est de connaître ce qui existe déjà dans ce langage, les librairies et comment les utiliser.

Ce dernier aspect est crucial pour la productivité d'un programmeur. C'est souvent au bout de plusieurs années qu'un développeur maîtrise aisément toutes ces API. Le problème est bien là : la maîtrise prend du temps. Et le temps, personne n'en a jamais assez.

C'est pour ça que la popularité d'un langage de programmation est rarement due à sa capacité à exprimer tous les paradigmes informatiques connus mais plus par sa capacité à montrer qu'il est le seul et unique langage qu'on vous demandera d'utiliser en milieu professionnel.

La période nécessaire d'apprentissage étant longue, un informaticien professionnel choisissant d'avoir quand même une vie en dehors de l'informatique et de son boulot, choisira nécessairement un seul langage.

A cause de cet apprentissage long, il est important de "maîtriser" au moins un langage de programmation, tout en gardant l'esprit ouvert sur les autres langages existants. Autant choisir un langage qui permet de mettre en œuvre un maximum de paradigmes. Même si il est vrai que le domaine du développement logiciel a largement avancé en restreignant ce que peuvent faire les programmeurs avec leur code, comme nous le rappelle Steve McConnell dans Code Complete 2 :
At one time or another, someone thought that each of the following control structures was a good idea:

- Unrestricted use of gotos

- Ability to compute a goto target dynamically and jump to the computed location

- Ability to use goto to jump from the middle of one routine into the middle of another routine

- Ability to call a routine with a line number or label that allowed execution to begin somewhere in the middle of the routine

- Ability to have the program generate code on the fly and then execute the code it just wrote

At one time, each of these ideas was regarded as acceptable or even desirable, even though now they all look hopelessly quaint, outdated, or dangerous. The field of software development has advanced largely through restricting what programmers can do with their code.

A vous donc, de choisir le bon langage de programmation pour lequel vous êtes prêt à investir un nombre d'heures déraisonnable pour en acquérir toute la maîtrise.

vendredi 15 août 2008

Système de suivi d'un développement logiciel

En milieu professionnel, le développement logiciel s'apparente à une construction d'une maison. On fait des plans à l'avance, et on s'organise pour que tout le monde travaille dans le bon sens. L'important est de pouvoir savoir que le projet avance, de suivre son avancement.

Rien de mieux pour cela que d'organiser un projet autour d'un système de gestion d'exigences, reflet exact du besoin du client. L'important dans un projet informatique est de s'assurer que toutes les exigences sont "couvertes", et que seules les exigences demandées sont implémentées. La liste des exigences n'est que le reflet exhaustif du contrat passé avec le client.

La gestion des exigences est parfois obligatoire notamment lors de marchés publics. Mais, même (et surtout) quand un contrat est ambigüe, n'est pas clair sur chacun des besoin du client, il est important de détailler le contrat en exigences.

Un des meilleurs bouquins que j'ai pu lire sur le sujet est Exploring Requirements: Quality Before Design de Donald C. Gause et Gerald M. Weinberg. Ce qui est intéressant dans ce livre c'est qu'il montre comment faire ressortir toutes les exigences d'un produit et comment les différencier en fonctions, attributs, contraintes, préférences et attentes.

Ainsi, quand on a plusieurs intervenant à faire travailler sur un projet, l'important est de s'assurer que le travail de chacun est lié directement à l'implémentation d'une exigence. La mise en place d'outils de gestion de projet devient inévitable dès qu'on a plus de 2 développeurs simultanés.

Le système d'information de base à mettre en place pour une gestion de projet s'articule autour des types d'outil suivant :
- un gestionnaire d'exigences
- un gestionnaire de tests, de scenarii de test et de plan de tests
- un outil de suivi des anomalies
- un outil pour relier au code les exigences et les anomalies.
- l'intégration de tous ces outils
L'idéal est bien d'intégrer tous ces outils pour avoir une maîtrise de ce qui est développé. Le processus de développement peut alors se décrire comme suit :
- une exigence est rédigée dans le système de gestion des exigences.

- des tests et des scenarii de tests sont rédigés pour cette exigence, permettant de s'assurer qu'elle a été correctement implémentée.

- des plans de test sont construits pour organiser les phases de vérification et de validation.

- quand un développeur veut commiter du code, il indique dans le message de commit la
référence de l'exigence concernée par ce commit.

- quand un test montre qu'il y a un problème, l'anomalie est tracée dans le système de suivi des anomalies.

- quand un développeur corrige l'anomalie dans le code, il indique dans le message de commit la référence de l'anomalie.
L'important dans tout ça est de contraindre le processus pour qu'il soit suivi :
- tout commit doit avoir soit une référence d'exigence, soit une référence d'anomalie
- toute anomalie doit avoir une référence à l'exigence sur laquelle le défaut a été constaté
- tout test doit avoir une référence à l'exigence testée
On peut mettre en place un tel système de suivi du développement logiciel avec de simples outils Open Source :
- Mantis pour le suivi des anomalies,

- Testlink pour le suivi des exigences, des tests, des scenarii de test, des plan de test. Il a l'avantage de s'interconnecter facilement avec Mantis. On peut faire correspondre des bug Mantis avec des tests Testlink.

- scmbug pour relier les commits au référentiels que sont les exigences et les anomalies.
Intégrer Mantis et Testlink est un jeu d'enfant, la mise en place de scmbug elle, est plus difficile (et le sera tant qu'il n'y aura pas d'interface au niveau de Mantis sur laquelle scmbug puisse connecter ses évènements).

Travailler avec un tel système nécessite d'adhérer à cette vision d'implémentation d'exigences. Il est important que chaque développeur comprenne que ce n'est pas contraindre la créativité que de baser le développement sur les exigences.

De toute manière, si vous avez correctement implémenté ce système, le développeur est obligé de préciser sur quelle exigence, ou quelle anomalie il commit son code, le tout est de s'assurer que le code correspond effectivement à ce qu'il prétend. Cela est normalement fait au niveau de l'assurance qualité.

mardi 12 août 2008

Les affres de la gestion de projet de développement au forfait

Pour les informaticiens travaillant en SSII, le travail sur des projets au forfait peut s'avérer beaucoup plus intéressant que de travailler en régie dans une équipe du client.

En effet, quand vous êtes en régie chez un client, vous avez beau être intégré dans les équipes en places et faire ami-ami avec vos collègues, vous n'êtes pas un employé de la société cliente, vous êtes un représentant de la société pour laquelle vous travaillez réellement, la SSII.

Travailler sur un projet au forfait dans la société qui vous à engagée est inconsciemment plus gratifiant que de travailler sur un projet d'un client. C'est mon sentiment personnel, ce n'est peut-être pas le cas pour vous, je le comprend bien.

Le problème d'un chef de projet en SSII, c'est que souvent, il récupère un projet au forfait qu'il n'a pas lui même vendu et dont il n'a pas estimé les charges. Ce découpage se retrouve souvent car le chef de projet a toujours tendance à avoir peur face aux risques qui apparaissent et donc à surestimer les charges de réalisation.

Le commercial ou chargé d'affaire, lui, est intéressé au chiffre d'affaire et est donc plus enclin à prendre des risques. Risques qu'il doit quand même mesurer pour qu'il puisse un jour espérer toucher sa commission lors de l'émission de la facture finale du projet.

Il se peut qu'on ne puisse pas évaluer correctement les charges de développement au début du projet, et c'est normal. La vente au forfait se base sur des présupposés et pré-requis plus ou moins explicités.

Le chef de projet, avant d'accepter tout nouveau projet doit comprendre entièrement les contraintes, présupposés, réserves et prérequis qui ont été utilisés pour l'évaluation des charges vendues au client. Il ne doit accepter de le gérer que suite à la revue complète de son estimation et de son acceptation.

Un projet au forfait engage la société de service:
- sur le résultat,
- sur le prix,
- sur les délais,
- et la qualité des produits livrés.
Le projet au forfait ne peut être viable que dans la mesure où une plus ou moins grande partie du cahier des charges est clairement explicitée et non ambiguë. Plus le cahier des charges est ambiguë, plus il y a de risque au forfait. Un client aura plus intérêt à internaliser les projets complexes (au niveau technique, organisation...)

Si vous vous trouvez dans la situation (si commune de nos jours) où on vous impose un projet qui vous semble intenable, plusieurs choses peuvent être entreprises pour arriver à s'en sortir :

Tout d'abord, il est important d'expliciter entièrement la formule qui a permis de calculer l'engagement au forfait (le nombre de jours, les délais, la qualité, etc.). Les commerciaux, chargés d'affaire doivent être capables de vous expliquer exactement ce qui leur à permis de mettre un prix de vente global sur la proposition commerciale.

Avec une telle formule, normalement apparaît tout de suite les éléments qui ont été sous-estimés par la "force de vente" (le commercial). Attention aux remises commerciales, concédées par le commercial pour gagner le projet "à tout prix".

Ensuite il est important de lister de façon exhaustive les points qui n'ont pas été explicité dans le contrat et qui auront un impact important sur le projet. Il s'agit souvent d'information provenant du client, que l'on n'a pas encore au moment de l'écriture du contrat. Le commercial a souvent un ressenti qu'il est important de recueillir car il n'est écrit nul part.

Identifier les exigences à risques et les exigences pour lesquels des solutions toute prêtes sont disponibles (soit en interne dans la société, soit par l'achat d'une brique sur étagère, soit par l'utilisation de technologies "Open Source".)

Enfin, d'après tous les éléments que vous avez à votre disposition, estimez les délais, coûts, qualité, ressources, risques et la rentabilité du projet.

Avec tous ces éléments, vous devez faire une réunion interne de lancement de projet pour remonter à votre hiérarchie toute ces informations et notamment toutes les charges que vous ne pouvez assumer (remise commerciales, flou dans le besoin client, flou dans la solution vendue.)

Rien de pire que d'accepter un projet infaisable sans broncher. Quand ça sera la cata (et ça sera la cata à un moment ou un autre !), ça sera vous le responsable !

Le plus important c'est que la société de service assume, dès le début du projet, les éléments que vous ne pouvez assumer seul. Et alors, seul le Compte Rendu de la réunion interne de lancement sera votre bouclier contre toutes les attaques qui se feront (forcément) jour lors du projet. Si vous ne pouvez pas faire de Compte Rendu, un email largement diffusé fera l'affaire.

L'important pour un chef de projet est de ne pas assumer les charges sur lesquels il n'a aucune prise. On ne peut être responsables des choses sur lesquelles on ne peut agir.

samedi 9 août 2008

Le chemin bien sinueux de l'excellence

On dit toujours qu'il faut savoir programmer quelque soit le langage. Mais, il est illusoire de croire que l'on peut arriver à un tel degré d'abstraction que l'on saurait alors coder proprement dans n'importe quel langage.

Bien que les bases de la programmation soient toujours nécessaires à acquérir d'une façon abstraite, la maîtrise d'un langage passe essentiellement par la connaissance aiguë des librairies offertes autour de celui-ci. Car un bon programmeur est avant tout un programmeur qui réutilise un maximum ce qui existe déjà.

Mais la capacité d'un programmeur à réutiliser des librairies existantes passe aussi par la compréhension des concepts véhiculées par celles-ci. La mesure de la compétence est quelque chose de difficile à estimer. La meilleur chose est de s'estimer en comparaison des véritables hackers, les demis-dieux, voire, les dieux tout court.

J'ai trouvé une matrice de compétence bien intéressante. Celle-ci offre une vue de ce que devrait être capable de faire un développeur expérimenté (ou avoir comme bagage), comme par exemple :
- Capacité du code à être lu (code readability) : les présupposés du code sont vérifiés par l'utilisation d'asserts, le code défile naturellement - pas d'emboîtement profond de conditionnelles ou de méthodes

- IDE : a écrit des macros personnalisées

- exposition aux langages : Concurrent (Erlang, Oz) and Logic (Prolog)

- années d'expérience professionnelle : 10+

- livres : Structure and Interpretation of Computer Programs, Concepts Techniques, Models of Computer Programming, Art of Computer Programming, Database systems , by C. J Date, Thinking Forth, Little Schemer
On retrouve plein d'idées d'amélioration de ses propres compétences, plein de sujet d'étude à découvrir.

Cela me fait penser à l'article "How To Become A Hacker" qui recense les caractéristiques d'un hacker, au sens "noble" du terme s'entend. Il est toujours bon de connaître le chemin même si l'important est de l'arpenter ensuite, comme dirait l'autre.

Le problème dans tout ça, c'est souvent le temps qui manque, et il n'est pas toujours facile de concilier la vie courante et la vie de hacker.

Où vous situez-vous dans la matrice de compétence, ou alors, pensez-vous que tout cela n'est pas bien réaliste et que les critères sont biaisés ?

mercredi 6 août 2008

Le contenu n'est pas une donnée

Il n'est pas toujours facile d'expliquer la différence entre du contenu et des données. Surtout à un développeur. Non, du contenu n'est pas simplement des données à stocker dans une base de données. Il faut prendre de la distance avec l'outil informatique. C'est ce qu'a très bien expliqué Seth Gottlieb dans son article "Content is not Data" :
1. Le contenu a une voix : le contenu essaie de communiquer quelque chose (exprimer une idée, convaincre quelqu'un). Cette communication demande un processus créatif et en entreprise, des approbations sont peut-être nécessaires avant sa diffusion.

2. Le contenu a un propriétaire : Les données n'ont généralement pas de copyright mais le contenu si.

3. Le contenu est destiné à un auditoire humain : les auteurs de contenu ont un souci constant d'un bonne présentation de leur contenu.

4. Le contenu a un contexte : En plus de savoir qui écrit le contenu, savoir où le contenu est présenté est aussi important.
Toutes ces caractéristiques du contenu implique des fonctionnalités que doivent proposer les CMS (Content Management Systems) notamment les plate-formes WCM :
1. Gestion des versions : le but est de suivre l'évolution d'un contenu. Selon le type de contenu, il peut y avoir de nombreux changements sur un même contenu. Il est important de pouvoir revoir des anciennes versions, comparer des versions, annoter des versions...

2. Gestion de la publication : la maîtrise de la diffusion et de la présentation du contenu implique des fonctionnalités importantes à offrir à l'auteur (éditeur WYSIWYG, prévisualisation, ...)

3. Feedback : il est important qu'un auteur ai un retour sur son contenu (commentaires, votes, statistiques, systèmes d'analyse d'influence...)

4. Métadonnées : stockage et exploitation des caractéristiques du document comme la source, le propriétaire, ...

5. Utilisabilité du système : pour faciliter la création et l'exploitation de contenu, car il est coûteux et difficile de produire du contenu de qualité.
Le terme de gestion de contenu chevauche la notion de gestion électronique de document (GED), qui elle, vise à stocker/indexer des documents électroniques (pdf, word...) ou des images de document papier.

On parle souvent de GED dans le cas de la numérisation d'un stock de documents papier existant. Dans ce dernier cas, on tombe souvent dans des problèmes de numérisation de vieux documents agrafés, recto-verso, A3, couleur, etc.

Des sociétés spécialisées, comme Jouve ou Xerox Global Services, s'occupent de ce genre de travail. On mesure le nombre de documents à traiter au mètre cube (m3). Il est assez difficile de s'engager sur une charge et des délais quand on ne connaît que le nombre de m3 à numériser, il faut alors donner une fourchette haute à l'estimation.

dimanche 3 août 2008

Architecture des Systèmes d'Information et le framework de Zachman

Le système d'information d'entreprise est apparu petit à petit dans l'entreprise, simplifiant certaines tâches répétitives ou compliquées. Bien qu'on pourrait croire qu'elle est issue d'une volonté forte des directions des entreprises, elle a souvent été introduite par de véritables passionnés, des amateurs qui, de leur poste de travail, ont su voir des applications novatrices de l'ordinateur.

Il n'est pas rare de rencontrer encore aujourd'hui des systèmes construits il y a fort longtemps, et maintenus jusqu'à aujourd'hui. C'est souvent le cas dans le monde de la banque ou dans les gros systèmes d'informations comme, par exemple, celui de France Telecom.

Quand l'informatique ne fait pas parti de la stratégie de l'entreprise, elle s'immisce petit à petit dans son environnement, jusqu'à contrôler des parties vitales de son l'activité.

J'ai vu en 1993, dans une entreprise de l'industrie chimique, un système construit de toute pièce par un enthousiaste de l'informatique. Le système a évolué du simple programme de suivi de l'activité d'une vanne au contrôle total d'une chaîne de production chimique de l'usine. Seules une ou deux personnes connaissaient le fonctionnement du logiciel (pas de documentation, pas de formation du personnels à l'informatique). Les personnes en charge de l'ouverture/fermeture des vannes se tournaient les pouces toute la journée, n'ayant plus d'opération à réaliser à la main.

On ne sait jamais ce que va devenir du code que l'on produit dès qu'on le lâche dans un environnement (une entreprise, sur internet...). Les entreprises ont voulu maîtriser leur informatique. Est apparu alors ce que l'on appelle "l'Architecture des Systèmes d'Information" qu'on rencontre aujourd'hui sous le nom de Architecture d'Entreprise, Urbanisme...

Nombre de méthodes et de cadres de travail sont apparus au cours du temps, et ce, depuis des lustres. L'un des travaux les plus intéressants a été la définition d'un cadre de définition d'une architecture d'une système d'information par J. A. Zachman, aussi nommé le "Zachman Framework". Le but était de trouver un cadre de travail pour cerner complètement l'ensemble des aspects d'une architecture d'un système d'information, sans contraindre les méthodes de travail.
On peut dire que Zachman a emprunter la méthode du reporter, du journaliste d'investigation. Pour tout système à analyser, il faut se poser les questions : quoi, comment, où, qui, quand, pourquoi (What, How, Where, Who, When, Why). En partant de ces différents aspects, il étudie le système à tous les niveaux de détail : de la stratégie d'entreprise à l'implémentation en passant par la conception, la construction...

En fait, il construit une sorte de hiérarchie de vues basée sur les différents métier de l'entreprise : Planner, Owner, Designer, Builder, SubContractor, Functioning Entreprise. Ce qui est vraiment intéressant avec ce cadre, c'est que les vues métier découlent les unes des autres : La vue Owner découle de ce qui a été défini au niveau de la vue Planner, la vue Designer découle de la vue Owner, etc.

En France, il n'y a pas eu de cadre comme le Zachman Framework mais une méthode très générique de spécification d'un système d'information d'entreprise : Merise. Cette méthode a défini différent modèles (MCD, MPD, MCT, etc.) qui se retrouvent dans le framework de Zachman. Merise a eu beaucoup de succès en son temps, mais il faut dire qu'aujourd'hui, seul le MCD/MLD ont réussi à résister au temps (même si on appelle aujourd'hui MPD alors qu'il s'agit la plupart du temps du MLD défini dans Merise).

Le temps passe, des méthodes apparaissent et disparaissent... Mais il faut bien séparer plusieurs notion :
- un cadre de travail : vision de l'architecture d'entreprise indépendante de la méthode de travail (par exemple : Zachman Framework)

- une méthode de travail : offre une définition claire des tâches et processus de travail pour obtenir une définition de l'architecture d'entreprise (Merise).

- un répertoire de bonne pratique : pour l'organisation du SI ou pour travailler sur la définition du SI (par exemple ITIL, CMMi).
Toutes ces notions ne recouvrent pas les même objectifs, et sont donc souvent complémentaires : on peut utiliser le framework de Zachman, en définissant des modèles Merise (MCD, MPD) en suivant un processus de développement logiciel basé sur CMMi tout en structurant les services IT autour de la notion de client/contrat : ITIL.

Il est rare de voir les entreprise adhérer à tous les concepts portés par ces notions. Le poids de l'existant est souvent trop lourd à porter. En effet, dès que le nombre de personnes entrant et sortant de l'entreprise est faible (le turnover), les personnes se mettent à travailler selon un schéma plus ou moins efficace mais avec une très forte inertie.

Et puis, il est plus risqué dans une grosse entreprise de faire les choses différemment plutôt que de faire comme tout le monde fait depuis des années sans se poser de questions. Les méthodes et cadres ont l'avantage de provoquer le personnel des entreprises en confrontant une vue "idéale" au monde des processus réels de l'entreprise.