Retour accueil

www.compucycles.com

imprimer

La crise actuelle de l’informatique Internet n’est pas seulement la fin logique d’une bulle spéculative.

C’est aussi une crise structurelle qui présente certaines analogies avec celle de 1991-1995, et qui pose, une fois de plus, le problème de la relation, volontiers conflictuelle, entre demandeur et concepteur de réalisation informatique.

A ses débuts, l’informatique Internet n’était qu’un sous-ensemble de l’informatique générale. Actuellement, ce serait plutôt un rejeton en train d’absorber son géniteur. En effet, secteur par secteur, les différentes fonctionnalités informatiques des entreprises migrent vers ce vecteur pour le transfert de l’information. Le phénomène se déclenche lorsque le besoin se fait sentir d’impliquer des acteurs géographiquement distants, intéressés par une diffusion quasi-instantanée de l’information.

Au fur et à mesure de ce glissement, les applications Web gagnent en complexité. A partir d'un seuil, on doit les concevoir, les développer,les monter en exploitation, en assurer la maintenance avec la rigueur suivie dans les chantiers d' informatique générale (en y ajoutant, bien sûr, le respect des contraintes qui sont propres à Internet).

Mais, apparemment, ce principe n'était pas évident pour ceux qui alimentèrent le rêve spéculatif : Comment a-t-on pu en arriver là ?

La décennie 1985-1995 fut l’ère des méthodologies (Merise, OMT, UML etc.). En tout cas, le principe du recours à une méthode était admis lorsque, vers 1996, le Web explosa sous le double coup de boutoir de Microsoft, qui imposa ses serveurs tournant sur PC, et de la montée en puissance au grand galop desdits PC qui se mirent à attaquer le monopole détenu jusque là par d’UNIX.

L'appel d'air fit s'engouffrer des débutants à peine formés, mais rejeta beaucoup de développeurs informatiques chevronnés, jugés trop vieux (que l'on affecta au Bug de l'An 2000, censé les occuper pour quinze ans).

... Et tout le monde se retrouva à la case départ des jeunes années 80, improvisant, bidouillant, rafistolant comme au bon vieux temps. Oubliées les méthodologies ...

Il faut tout de même reconnaître que celles-ci avaient donné des verges pour se faire battre ! Elles avaient une image de pesanteur et de coût prohibitif.

En fait, leur drame est de pas avoir été appliquées par les acteurs prévus : Elles avaient été conçues comme un outil de dialogue, à parité, entre utilisateurs et informaticiens. Or ces derniers étaient trop souvent amenés à conduire seuls l’analyse, faute d’un goût prononcé pour le dialogue - peut-être - , mais aussi parce que le formalisme de représentation des traitements (en particulier le MCT/MOT, selon le vocabulaire Merisien) était illisible pour les utilisateurs, qui ne pouvaient donc pas donner leur indispensable validation.

En parallèle (1990 - 2000) se développèrent d’autres thèmes porteurs, tels que les structures clients/serveur (promises à un bel avenir), l’ « orienté Objet » (expression dont on usa et abusa). Puis dans un cadre beaucoup plus vaste, la « démarche Qualité » et les efforts de normalisation.

L’AFNOR publia en 1991 une série de normes centrées sur l’ « analyse de la valeur » : X 50-100, X 50-151, X 50-152, X 50-153. La seconde de cette série est axée sur le "cahier des charges fonctionnel" (abréviation : "CdCF"), et fit figure de référence en la matière.

Cet effort de normalisation se voulait très général : Il ne faut pas perdre de vue que le précurseur de ce mouvement était le BTP. Beaucoup restait à faire pour que le secteur de l’informatique puisse en tirer un profit direct. Mais il avait le mérite d’identifier certaines préoccupations majeures qui apparaissent d’une actualité urgente aujourd’hui, en cette phase de crise, tant la relation entre demandeurs et prestataires ressemble aujourd’hui, dans le domaine Internet, à un conte du folklore russe intitulé :

L’idée directrice est que :

• le cahier des charges est l’oeuvre du demandeur
  Le demandeur se trouve donc réinvesti dans ses responsabilités et cela avant tout contact avec un prestataire. Par ailleurs, il n'est astreint aucun formalisme graphique.

• Ce demandeur identifie, et exprime par écrit, ses besoins en termes fonctionnels,
  
• Il précise les contraintes et leurs limites (leur « flexibilité »).
  Il formule son besoin en terme de résultat attendu, et ne se prononce pas sur le choix des moyens. Il sort ainsi son besoin des limbes de l’inconscient, et en fait une « attente» dont les contours sont précis, et qui servira de cadre à un engagement réciproque (le futur document contractuel).

• Il élabore ainsi un document qui permettra un appel d’offres, donc une compétition équitable,
  
• Il précise les critères d’appréciation qui orienteront son choix parmi les propositions qui seront soumises
  La norme invite donc à agir dans le cadre d’une certaine éthique professionnelle.

• Ce document est conçu pour servir de cadre de réponse aux candidats,
  Ce qui devrait faciliter la comparaison de leurs propositions.

Il s’agit donc d’anticiper sur la future relation contractuelle, en permettant à chacun de prendre conscience, le plus tôt possible, de ses responsabilités,

il s’agit de gagner du temps, de travailler efficacement et d’éviter les déceptions.

Il est certain que l’élaboration d’un cahier des charges est une astreinte : Il va falloir poser un regard lucide sur l’existant de l’entreprise, se documenter sur les possibilités d’un secteur parfois mal connu, identifier les besoins et les améliorations possibles, concilier les opinions, formaliser par écrit ce qui est le début d’un engagement, prendre le risque de l’erreur.

La tentation est grande de l’esquiver. Mais le simple fait de s’engager sur des bases floues risque d’occasionner :

• Une multiplication des entretiens avec les candidats, redites, perte de temps, voire un harcèlement téléphonique pour obtenir les éléments nécessaires à la réponse,

• L’influence des candidats cherchant à vendre un produit préexistant, qui n’est pas nécessairement adapté au contexte, ou « poussant à la dépense »,

• La sélection du candidat final sur des critères irrationnels ,

• Des lacunes dans le document contractuel ultérieur (qui sera probablement rédigé par le prestataire sélectionné), d’où un risque de tensions et de difficultés juridiques,

• Une sous-estimation de l’engagement financier , une dérive du calendrier,

• Sur le plan qualitatif, un résultat décevant et ne permettant pas d’évolution .

En somme, en voulant faire l’économie de cette phase, on favorise l’installation d’une situation de dépendance vis à vis du prestataire, et on ne fait que retarder un travail d’investigation qui se révélera, de toute façon, inévitable.

c’est le moyen de disposer d’emblée d’un maximum d’éléments lui permettant :

• d’estimer s’il est possible d’installer une relation fructueuse avec le demandeur .
  En clair : Ce dernier marie-t-il harmonieusement exigence, lucidité, raison et correction (… et si possible solvabilité) ?
  
  
• de vérifier si la tâche correspond à son propre créneau , et à ses disponibilités.
  
  
• de démontrer qu’il est apte à comprendre une problématique complexe à partir d’un document écrit,
  
  
• de faire valoir ses compétences et ses expériences en ce domaine,
  
  
• de chiffrer sa prestation ,
  Et c’est là la pierre d’achoppement : Aussi surprenant que cela paraisse, en informatique, un développement original (par opposition à un logiciel simplement adapté au nouveau contexte) est une opération souvent difficile à chiffrer , sauf à disposer d’un descriptif précis.

... Tout ceci, en y consacrant le moins de temps possible, sachant que ce travail ne lui sera peut-être jamais rémunéré, et en espérant qu’il ne s’agit pas d’un « faux appel d’offres » (l’heureux élu est déjà choisi, la procédure ne sert qu’à donner une apparence d’objectivité).

La Norme utilise à plusieurs reprises le terme d’ «analyse fonctionnelle». Mais il s’agit là d’une terminologie très générale. Cette notion a donc été parfois été confondue avec le sens qu'a cette expression dans le cadre précis de l’analyse informatique, et en particulier dans sa phase «conceptuelle», ce qui est en partie un contresens, puisqu’un cahier des charges n’a pas lieu de modéliser les données. En revanche, il reprend une grande idée de l’approche « top - down » des méthodologies, qui consiste à commencer par considérer la chose comme une « boîte noire » : On identifie ce qui rentre et ce qui sort de la boîte, mais on ignore délibérément ce qui s’y passe, du moins durant les premières phases.

Idéalement, le cahier des charges devrait donc préciser l’amont et l’aval des traitements :

• Evidemment le « Quoi ? » limité aux aspect fonctionnels (ce qu’on appelle les « règles de gestion »), les exigences de qualité, les aspects quantitatifs, l’intégration dans un existant éventuel, voire le contexte juridique, humain etc.).

• Mais également le « Qui ? »(les différents publics destinataires des pages), le « Pourquoi ? », le « Quand ? », le « Où ? ».

Attention : ces questions ne correspondent pas à la typologie classique de Merise, par exemple. Ainsi le « Quoi ? » ne recouvre pas, ici, la notion de MCD. En revanche, il présente bien des analogies avec le domaine des MCT / MOT.

En bref, il faut exposer à peu près « Tout » … à deux exceptions près, de taille : le «Comment ?» et le «Combien ?» (budget) qui sont - et c’est le but du jeu - à la charge du candidat.

Ajoutons au lot du prestataire - ce qui est moins évident - un regard critique sur la faisabilité de l'opération, une identification des risques voire des mises en garde éventuelles, comme le ferait - dans un autre contexte - un bon avocat, un bon médecin, un bon architecte, parfois au risque de perdre un client

Il s’agit, en somme, de tester les compétences du candidat sans lui imposer une charge de travail excessive. Il peut donc parfois être utile d’omettre certains points délibérément, permettant ainsi d’apprécier ses réactions, son aptitude à l’identification des problèmes et son expérience du métier.

Inversement, dans certains cas, il se peut que le demandeur soit amené à empiéter sur le terrain des prestataires.

Comme pour toute application informatique, il peut être judicieux de préciser un cadre juridique concernant les règles de propriété sur la future application (afin d’éviter que dans le cas d’un produit coûteux, réalisé « sur mesure », il ne soit ultérieurement revendu aux concurrents du demandeur), et certains points de déontologie (confidentialité, concurrence déloyale etc.).

Il ne faut pas non plus perdre de vue l’évolution du contexte juridique concernant Internet, en particulier en matière de droits d’auteur pour les images, les sons, les textes, les règles de dépôt des noms de domaine et les responsabilités..

Dans tous les cas, s’il y a lieu à dépôt d’un nom de domaine , préciser les rôles (le dépôt doit-il être effectué par le prestataire ? y a-t-il lieu à recherche d’antériorité, à dépôt d’un nom de marque auprès de l’INPI ? Qui se chargera de surveiller les dates d’échéance etc.). Il faut souligner le danger qu'il y a à ne pas surveiller l'échéance des noms de domaines (surtout les ".com"), certains sites n'hésitant pas à diffuser la liste des noms susceptibles de tomber prochainement dans le domaine public : En fait, le droit d'usage d'un nom de domaine n'est que "loué" (comme un nom de marque, d'ailleurs, mais à échéance plus brève).

Ne pas oublier, non plus, que la déclaration à la CNIL (Commission nationale Informatique et Liberté) est obligatoire dès que des données personnelles figurent dans un fichier informatique quel qu'il soit (cela n'a rien de particulièrement "Internet", mais là, ça ce voit !). Compter un délai de deux mois (sous toute réserve) pour la réponse.

• S’il l’informatique Internet est appelée à s’articuler avec un système Informatique existant , donner des informations sur ce dernier (système d’exploitation, langages, gestionnaire de base de données, structure de la base de données, interfaces, logiciels etc.)

• Si le futur site est appelé à remplacer un système existant non-informatique de traitement de l’information (courrier, documents imprimés, téléphone etc.), préciser ses règles de gestion.

• Si le futur site est appelé à remplacer un système existant informatique , prévoir un descriptif (ce qui permettra de chiffrer la «reprise» des données existantes, qui peut, dans certains cas, représenter un poste important du budget).

• S’il s’agit d’une refonte de site Internet , exposer les motifs de l’insatisfaction.

  Et d’une manière générale :

• Préciser le rôle des différents acteurs par rapport à la future application (en particulier, concernant les droits d’accès aux informations de la base de données), et s’il y a lieu, l’évolution de leurs responsabilités.

• Présenter de manière comparative les aspects quantitatifs .

Il appartient, en principe, au candidat de faire des suggestions pour le choix de l’hébergeant et de présenter son coût, les caractéristiques du serveur hôte, les services proposés : En effet, si le prestataire est familier de l’hébergeant retenu, certains aspects peuvent être facilités.

(Remarque : Si le site est situé à l’étranger, prévoir éventuellement l’impact sur la gestion des dates, tels que décalage horaire, gestion des dates « mm/jj/aa » etc. ).

Ceci étant, il se peut que le demandeur souhaite imposer un hébergeant.

Par ailleurs, les exigences en matière de disponibilité du site doivent rester vraisemblables : Il est normal qu’un serveur soit arrêté périodiquement pour des maintenances (actuellement, on ne peut raisonnablement demander une disponibilité du serveur supérieure à 95% du temps total)

Les distinctions Internet / Extranet / Intranet ont perdu de leur netteté. Ceci dit, on utilise fréquemment « Internet » pour désigner des pages accessibles par tous, alors que ce mot désigne, en fait, une réalité très vaste constitué d’un ensemble de protocoles (le Web : "http", les transferts de fichiers : "ftp", email etc.)

Du coup « Extranet » est censé désigner les pages réservées à un public restreint (abonnés à un service, par exemple) filtré par mot de passe, et « Intranet » des sites à usage exclusif de l'entreprise, et en principe hébergés sur un serveur installé dans ses locaux (mais ce dernier point est de moins en moins vrai).

En fait, le principal intérêt de cette distinction est que dans un contexte Intranet, le navigateur est imposé, ce qui élimine les questions de compatibilités. De plus, si, dans ce contexte, le serveur est physiquement local, les risques d'intrusions sont relativement limités.

Toujours est-il que les règles d’ accessibilité des pages doivent être détaillées.

Le nombre des intervenants en mise à jour de la base de données doit également être précisé : Suivant les cas, les problèmes de concurrence d’accès doivent être gérés, ou non, au niveau des développements.

Sans forcer le trait, le contexte Internet est plus vulnérable que celui de l’informatique générale. La plupart des sites ne justifient pas de stratégies draconiennes de protection (des règles de bon sens - en particulier au niveau de la programmation - suffisent en général) mais il faut mentionner l'existence éventuelle de données particulièrement sensibles.

Autre distinction : Un site est en général permanent, mais un site temporaire ou périodique (le temps d’un salon, par exemple) peut également représenter une formule intéressante, car peu coûteuse (en raison d’une présentation, en général, plus « standard »).

Le gestionnaire de base de données est en principe suggéré par le prestataire, mais le demandeur peut avoir une opinion sur la question : On peut observer des souhaits insistants pour des gestionnaires de gros calibre (SQL server, pour citer un exemple du contexte Windows), alors que ce type de choix a des conséquences budgétaires notables au niveau de l’hébergement, des développements et de la maintenance.

Il faut garder à l’esprit qu’un temps de réponse Internet dépend, comme toute chaîne, de son maillon le plus faible, et que la qualité de la programmation et le respect de quelques principes simples jouent, en fait, un rôle essentiel dans ce mécanisme.

Là encore, il s’agit d’un point qui est théoriquement du ressort du prestataire. Mais rien n’empêche un demandeur d’exprimer ses préférences (dans le souci, par exemple, d’assurer la meilleure cohérence possible entre gestionnaire de base de données et langage).

Cette question relève typiquement de la réponse des candidats. Néanmoins, le point est mentionné pour mémoire, car la première tâche à laquelle s’attelleront les candidats sera probablement de tenter une ébauche de la structure de la base.

Il faut percevoir que la part occupée par les traitements dits « de gestion de la base de données » représentent la part immergée de l’iceberg, soit facilement les 3/4 de la totalité d’un budget. Il s’agit des traitements de création / modification / suppression des enregistrements permettant d’actualiser à distance et instantanément les informations consultables sur les pages « publiques » du site (les références d’un catalogue, par exemple).

La qualité d’une application informatique dépend, en très grande partie, de ces programmes qui sont longs et rébarbatifs à écrire et nécessitent des procédures de tests très soigneuses. Dans les produits bon marché, cette phase est bâclée. Le risque est alors que la base se pollue insidieusement.

Or, en informatique Internet on a plus spécialement tendance à se focaliser sur les pages publiques (de consultation des données), en sous-estimant l’importance de cette «arrière-boutique» (le «back-office» pour les anglicistes).

En simplifiant, le coût de cette part des développements est pratiquement proportionnel au nombre de tables de la base, et dépend également du nombre et de la nature des contrôles effectués sur les champs de saisie. Pour établir son devis, le candidat doit évaluer approximativement ces données, et donc disposer d’emblée d’informations relativement complètes.

Il faut prévoir qui se chargera des traductions, ce qui reste une question classique.

Mais il faut également percevoir le moment où le nombre des langues risque de bousculer la structure même des développements.

En effet, pour faire au plus simple, les libellés à traduire peuvent être « statiques » (en clair : écrits directement dans le code HTML, sans recours à la programmation). On peut alors se contenter de dupliquer simplement les pages dans les différentes langues, tout en gardant à l’esprit que s'il faut modifier des pages, il faudra reporter les modifications, manuellement, sur les pages jumelles des autres langues.

En revanche, si les pages sont nombreuses et si le site est multilingue, on peut préférer opter pour une formule « dynamiques » (concrètement, les libellés, eux-mêmes, sont stockés dans une base de données, et utilisés sous forme de variables). Les pages n'ont alors pas lieu d'être dupliquées (ce qui simplifie la maintenance), mais si la mise en page est très précise, elle risque d’être bousculée par le volume du texte, extensible selon les langues.

La qualité de la navigation (l’enchaînement, interactif ou non, des pages du site) est l’une des composantes essentielles de l’efficacité d’une application Internet.

L’ergonomie a pour rôle de réussir un compromis harmonieux entre la limpidité de chaque page et un accès aussi rapide que possible à l’information recherchée. Le travail préparatoire consiste donc à classer hiérarchiquement des informations en fonction des intentions supposées des visiteurs.

Sur le plan technique la mise au point de la navigation suppose une bonne perception des possibilités offertes par les découpes de fenêtres (les "frames") et les fenêtres secondaires (fréquemment dénommées "pop-up").

En contrepartie, la multiplication des pages peut alourdir notablement le budget. En effet (et c’est une particularité de l’ informatique Internet) la transmission des informations d’un écran à l’autre (ou la conservation d’informations persistantes au cours d’une même session) peut nécessiter des procédés acrobatiques si la navigation impose, par exemple, de pouvoir passer de n’importe quelle page à n’importe quelle autre.

Dans tous les cas, le dialogue serait grandement simplifié si le demandeur était en mesure de fournir, dès le cahier des charges, une représentation très schématique des pages, permettant au moins d’apprécier la répartition des zones de saisie, page par page, et les enchaînements entre les différentes pages.

Si le cahier des charges prévoit des réalisations graphiques, préciser s’il existe déjà une charte graphique ou si elle doit être élaborée par le prestataire. Dans ce cas, les intentions du demandeurs devraient être précisées (pour éviter, par exemple, une dérive coûteuse vers une utilisation d’animations qui ne correspondrait pas au style de site attendu. Idem pour la sonorisation du site).

Si la mise au point graphique n’a pas lieu d’être réalisée par ce prestataire, il faudra tenir compte du fait que l’articulation entre développements informatiques et réalisations graphiques n’est pas nécessairement une opération simple, et qu’elle peut révéler des difficultés imprévues, surtout dans le cas d’une exceptionnelle densité d’information (situation aggravée par l’interdiction des barres de défilement sur les pages, par exemple)

Comme dans toute application informatique, l’usage des champs de saisie doit toujours être contrôlé. Mais dans le cadre d’Internet, ces contrôles revêtent une importance particulière (du fait de l’ouverture des pages au public), et, pour des raisons de confort de l’utilisateur, il est bien préférable que ces contrôles soient écrits en Javascript, chaque fois que c’est possible.

Or, en cas de développements Javascript importants (qu’il s’agisse de contrôles de saisie ou d’un autre usage), trop d’exigences en matière de compatibilité peut pénaliser lourdement le budget, en provoquant une multiplication des tests et des corrections. En effet, l’exécution de ce langage dépend de l'équipement matériel du visiteur : éditeur et version du navigateur, système d’exploitation (Mac ou PC, voire UNIX), sans compter le problèmes de variation de mise en page suivant la résolution de l’écran (800 x 600 pixels ou 1024 x 800 pixels).

D’une manière générale, plus le Javascript sera écrit de manière correcte mais rudimentaire, plus il a des chances d’être largement compatible.

Les développeurs sont responsables de la qualité des tests «unitaires» (c’est à dire au niveau d’un traitement pris isolément) et d’ «intégration» (qui ont pour objet de vérifier l’enchaînement des traitements).

Mais le demandeur doit être conscient que ses propres équipes doivent participer aux tests «utilisateurs», car ils pratiqueront les traitement selon une démarche qui leur est propre, que l’on ne peut demander aux informaticiens car ce n’est pas leur métier.

A l’occasion de ces tests, des dysfonctionnements inattendus peuvent être provoqués ce qui est normal, et doit donc avoir été prévu dans le budget.

On observe, dans la pratique, que cette phase est souvent esquivée par tout le monde !

Le prestataire, bien sûr, craint la détection d’erreur de programmation, (ou d'analyse, ce qui est plus grave),

Mais le demandeur également - qui doit y affecter un budget-temps de son propre personnel - craint de devoir reconnaître des lacunes au niveau de la définition du chantier.

Il faut admettre que cette phase inconfortable est indispensable, d'autant plus qu'elle prépare la phase finale de validation. Il est donc préférable qu’ elle soit explicitement prévue.

Après la mise en place définitive du site, le client disposera-t-il du FTP (protocole de transfert de fichiers, qu’ils s’agisse des programmes ou des données) ? Si oui, quand le mot de passe lui sera-t-il remis ?

En principe cette opération a lieu après la validation et le règlement du solde du budget.

Elle n'a de raison d'être que si le site est installé sur un serveur distant (ce qui est le cas le plus fréquent), et c'est là un élément important de l'autonomie du demandeur.

Toujours dans le cas où le site est installé sur un serveur distant, il peut être préférable de prévoir explicitement une remise du texte des programmes après la validation finale (sous la forme d’un CD-Rom, par exemple).

En effet, si le prestataire disparaît, ou si un conflit survient avec lui, la récupération des programmes via le FTP peut être une opération aléatoire.

Si le placement dans les extractions des moteurs de recherche est un point important pour le demandeur, les pages-pivôt du site devront satisfaire à certaines contraintes techniques (mots-clés, descriptifs etc.). Il convient également de définir les rôles pour les opérations de déclaration auprès des moteurs de recherche.

Il peut être prévu un manuel (pour les traitements de gestion de la base de données), ou quelques heures de formation sur place du personnel, ou une hot line.

Ces solutions sont « classiques ». Mais une solution plus «Internet» peut consister à intégrer l’aide aux pages mêmes du site.

Les conditions de la maintenance et de l’évolution doivent être particulièrement prises en compte, car, dans le contexte Internet plus qu’ailleurs, la pérennité des prestataires fait figure d’illusion (et cette remarque ne préjuge en rien de leur qualité).

La maintenance sera simplifiée si :

• Les traitements sont rédigés de manière modulaire, structurée et bien documentée (c’est là un vœu formulé dans toutes les branches de l’informatique, mais il peut être bon de le rappeler)

• Les traitements sont écrits en «mode natif», plutôt qu’à l’aide de générateurs de source.
  Bien entendu, cette position est à nuancer en fonction du générateur, mais il est certain que le mode natif est moins "propriétaire".

Un site Internet complet peut, dans certains cas, être une vaste opération, longue et coûteuse.

Mais, avantage du contexte Internet, les développements peuvent être livrés de manière échelonnée. Il est probable qu’à ces occasions, des bifurcations s’avéreront nécessaires, des idées nouvelles se grefferont.

On ne peut que suggérer de ne pas surcharger les premiers développements, mais de procéder par étapes distinctes, en procédant par cercles concentriques à partir d’un noyau simple mais très bien conçu, tout en anticipant sur les évolutions ultérieures.

Il est d’ailleurs probable que le prestataire se chargera de faire des suggestions de fonctionnalités périphériques : moteurs de recherche intégré au site, forum, gestion d’emails, traitements statistiques etc. La question sera de savoir s’il s’agit là de conseils judicieux, ou d’une incitation à la dépense.

S’il n’y a aucune contrainte particulière concernant la date de mise en service, il vaut mieux laisser le candidat apprécier le délai nécessaire (La qualité du travail ne gagne rien à une réalisation dans l’urgence). Ce point pourra d’ailleurs être un bon argument de négociation budgétaire.

En revanche, si des dates de l’échéancier sont réellement impératives, il convient de le préciser.

Ceci étant, il est indispensable de prévoir dès le début le principe de jalons de validation :

• Pour le demandeur , c’est l’assurance de l’exécution normale d’une livraison étagée.
  
• En retour c’est, pour le prestataire, l’assurance d’un engagement contractuel de la part du demandeur et il est souhaitable que ces jalons correspondent à un règlement partiel des engagements financiers.

Certains demandeurs expriment, dès la rédaction du CdDF, des souhaits concernant l’équipe de développement .

Mais il faut souligner que son importance numérique ne joue pas nécessairement un rôle positif, car la coordination des travaux de développeurs différents constitue, en soi, une tâche difficile.

Mais pour un site complexe, un concepteur très qualifié doit impérativement initier le travail (notamment au moment de la mise au point de la structure de la base de données et du découpage en traitements). Mais la présence à plein temps de ce type de profil est difficile à exiger de petites structures.

De même pour les graphistes : il est fréquent qu’il s’agisse de free-lance, et cela ne constitue pas un point négatif.

En revanche, il est de première importance que des informations soient fournies sur les méthodes qui sont suivies (en particulier au niveau de la conception et des protocoles de tests).

Par ailleurs, le regroupement des opérations par lots cohérents peut amener à répartir la tâche entre plusieurs prestataires en fonction de leurs spécialités respectives. L’usage de l’Internet (comme mode de communication entre eux) leur permettant d’articuler leurs travaux avec une relative souplesse.

En marge, concernant l’exigence de «références», il faut reconnaître que cette pratique, très anglo-saxonne, suppose un certain «fair-play» ...

Traditionnellement, le mécanisme de l’appel d’offres se décompose en :

• L’appel à candidature, avec envoi d’un document succinct, (souvent appelé lui-même «appel d’offre», par extension),
  
• L’envoi du cahier des charges aux candidats,
  
• La réponse des candidats, sous la forme d’une proposition chiffrée,
  
• Les entretiens, au cours desquels le cahier des charges peut être ajusté en fonction des suggestions des candidats,
  
• La sélection du candidat,
  
• La signature du document contractuel.

Mais l’usage de l’Internet permet d’alléger cette procédure en mettant en ligne directement et sans frais le texte intégral du cahier des charges (sous réserve de dispositions confidentielles, bien entendu).

Tandis que les candidats peuvent, eux-mêmes, transmettre leur proposition par email sous la forme de documents joints visualisables à l’écran, qu’ils n’envoient sous forme imprimée qu’en cas de pré-sélection.

Autre possibilité de réponse : créer des pages Internet et fournir l’adresse au demandeur. L’intérêt de cette formule est d’en permettre l’actualisation de manière permanente et instantanée.

L’informatique, et Internet plus encore, est une science bien trop récente pour que l’on ait le recul nécessaire à l’analyse du cycle de ses crises.

Mais il semble bien qu’un point soit annonciateur des périodes de trouble : Lorsque la formulation des demandes dérape systématiquement vers une sur-estimation des besoins technologiques, et à une sous-estimation dramatique des besoins en analyse préalable.

Cela peut être le signe que le terrain devient favorable à un certain charlatanisme.

Le mouvement actuel, cherchant à promouvoir l’usage du cahier des charges, tend à déplacer au maximum le travail d’analyse vers l’amont, à le mettre à la charge du demandeur lui-même.

Mais, si les demandeurs, dans le cadre des méthodologies «classiques», n’étaient pas parvenus à faire valoir leur voix alors qu’ils étaient censés collaborer avec les développeurs, il leur sera difficile d'y parvenir une fois laissés à eux-mêmes dans le cadre d'un cahier des charges.

Le plus surprenant de la situation est que, concernant une possibilité de réalisations très prometteuses, capable de réellement stimuler un marché en plein marasme, mais nécessitant un minimum de documentation et d’expérience, les ouvrages sont rares, et Internet lui-même n’est pas d’un grand secours.

Les hésitations seraient d’autant plus dommages que, pour une personne expérimentée, l’élaboration du cahier des charges d’un site Web représente, d’habitude, entre deux jours et une semaine de travail.

Il peut être tentant de s’adresser à un conseil extérieur. La question sera alors de s’assurer de sa compétence … et de beaucoup de qualités qui relèvent de l’éthique professionnelle. Vaste domaine qui va de l’objectivité à la discrétion !

Les différents sujets traités dans ce site se recoupant, les bibliographies ont été regroupées : Bibliographie

IDDN.FR.010.0099871.000.R.P.2002.035.20600

Conformément aux conventions internationales relatives à la propriété intellectuelle, cette oeuvre est protégée. Le titulaire des droits autorise : La reproduction et la représentation à titre de copie privée ou à des fins d'enseignement et de recherche et en dehors de toute utilisation lucrative. Ceci, sous réserve que soient indiqués clairement le nom de l'auteur et la source (IDDN de l'oeuvre), tels que signalés dans le présent document.

Retour accueil

www.compucycles.com

imprimer