Espaces clients et extranets

Quel espace connecté pour quel public

Le vocabulaire du secteur brouille plus qu’il n’éclaire. Extranet, portail, espace connecté, plateforme collaborative désignent des produits très différents selon l’éditeur qui les vend. Nous-mêmes employons « extranet » comme étiquette commune aux quatre espaces présentés plus haut, intranet compris, par commodité de langage : au sens strict, un intranet ferme l’accès vers l’extérieur là où un extranet l’ouvre, mais le secteur range les deux sous le même mot faute de meilleur terme partagé. Deux questions suffisent à ranger un projet : qui se connecte, et ce que cette personne vient y faire.

Le public sépare d’abord le dehors du dedans. Vos clients et vos partenaires arrivent de l’extérieur, avec des comptes que vous créez et des données cloisonnées dossier par dossier. Vos salariés arrivent de l’intérieur, avec une identité que votre entreprise gère déjà. L’usage tranche ensuite, à public identique : consulter ce que l’entreprise publie, ou agir sur son propre dossier. C’est cette seconde question qui départage un intranet d’un portail collaborateurs, tous deux ouverts aux mêmes salariés.

L’ordre de mise en œuvre compte autant que le choix lui-même. Commencer par le public qui génère le plus de sollicitations donne le retour le plus rapide, et laisse un socle technique, comptes et droits en tête, que le suivant réutilise sans le redévelopper.

Ce que votre système actuel sait déjà exposer vers l’extérieur

Nous inspectons vos outils en place avant de produire la moindre maquette. Cette étape a lieu même quand vous nous annoncez partir de zéro, parce qu’un départ de zéro n’existe jamais vraiment : les données que l’espace affichera vivent déjà quelque part, dans un logiciel de gestion, une base, des fichiers, parfois la boîte mail d’une seule personne.

La question qui gouverne ce type de projet porte sur l’ouverture. Nous vérifions si votre logiciel expose une interface de programmation ou seulement des exports de fichiers, si des comptes utilisateurs existent déjà et sous quelle forme, si votre hébergement accepte de publier une application vers l’extérieur, quelles conditions votre informatique pose à cette publication, et dans quel état sortent vos données, doublons et champs vides compris.

Les réponses déplacent le projet. Un logiciel fermé impose un autre chemin d’alimentation, par export planifié plutôt que par lecture directe. Un fichier client à moitié rempli demande un nettoyage avant l’ouverture, sous peine d’exposer vos approximations internes à vos clients dès la première semaine. Une découverte de ce genre se traite au cadrage. La même, faite en plein développement, oblige à revenir sur des écrans déjà livrés.

Quand une demande de changement arrive en cours de développement

Les demandes de changement n’arrivent pas au hasard : elles surviennent au moment du test utilisateur décrit plus haut, une fois le prototype entre les mains de ceux qui l’utiliseront. C’est bon signe, et c’est aussi ce qui met en difficulté les projets menés d’un seul tenant.

Nous développons donc par lots testables. Chaque lot couvre un ensemble d’écrans cohérent, part sur un environnement de test, et s’ouvre à quelques utilisateurs. Une demande qui arrive à ce moment-là entre dans le lot en cours ou dans le suivant. Elle laisse intact ce qui est déjà livré et validé.

Cette règle a deux effets pour vous. Le résultat arrive par morceaux utilisables, plutôt qu’en une livraison unique dont vous découvrez tout le jour de la mise en ligne. Et le périmètre reste discutable jusqu’au bout, sans que chaque discussion remette le calendrier entier en cause.

Les trois postes qui pèsent sur le budget d’un extranet

Le chiffrage d’un espace connecté se joue sur trois variables, avant tout le reste.

Le nombre de publics d’abord : un deuxième profil d’utilisateur ne double pas la charge, il ajoute des écrans, des règles d’accès et des cas à tester. Les connexions ensuite : brancher un outil qui expose une interface propre demande peu de travail, récupérer les données d’un logiciel fermé en demande beaucoup. La finesse des droits enfin. Un accès par compte se construit vite. Des droits croisés par entité, par rôle et par dossier, avec leurs exceptions, occupent une part réelle du développement.

Le volume d’utilisateurs, lui, pèse peu. Un extranet ouvert à cinquante partenaires et un extranet ouvert à cinq mille se développent pour un coût comparable, puisque vous ne payez pas de licence par compte. C’est ce qui rend le calcul différent d’un abonnement, dont la facture suit le nombre d’utilisateurs déclarés.

Le délai suit le même calcul que le budget : un accès unique, déjà bien exposé par votre logiciel, se compte en semaines. Un extranet à plusieurs publics, avec des droits croisés et un système fermé à interroger, se compte en mois. Le cadrage resserre ce repère sur votre cas réel.

Reprendre un extranet existant plutôt que repartir de zéro

Certains projets portent sur un espace déjà en ligne. Il a été développé il y a cinq ou huit ans, son prestataire n’est plus joignable, et personne n’ose y toucher. La question posée porte moins sur le fait de tout refaire que sur ce qui mérite d’être conservé.

La réponse tient à trois choses : l’état du code, la structure de la base de données, et le nombre d’utilisateurs actifs. Une base bien structurée se conserve, même quand l’interface part entièrement. Des comptes en service se reprennent avec leurs mots de passe, ce qui évite de redemander une inscription à des clients ou à des partenaires qui se connectent depuis des années. Un code devenu illisible se remplace module par module, pendant que l’ancien continue de tourner.

Nous traitons ces reprises dans nos projets de refonte et reprise de projet, avec le même audit de départ que pour un développement neuf.

Un extranet sur-mesure qui reste le vôtre

Un extranet héberge les comptes et les données des personnes que vous y faites entrer. La question de savoir à qui tout cela appartient se tranche donc au départ, dans le contrat de développement lui-même. Vous recevez à la livraison le code, la base et les droits qui vont avec.

Cela a trois conséquences concrètes. Vous déplacez l’application chez l’hébergeur de votre choix sans nous en demander la permission, et les noms de domaine restent à votre nom. Vous continuez de vous en servir sans souscrire quoi que ce soit auprès de nous. Et nous travaillons sur des technologies largement pratiquées, que n’importe quelle équipe technique reprend sans dépendre de nous.

Nous assurons ensuite les évolutions des espaces que nous livrons, quand nos clients nous les confient. Cette suite de travail se rediscute sur ce qu’elle vaut, et elle reste votre décision.