Développement d’intranet sur mesure à Paris

Un intranet sert vos équipes, un extranet ouvre un accès contrôlé à des partenaires ou clients, un outil métier traite un processus précis. Un même projet peut combiner les trois, avec des droits distincts.

La distinction n’est pas décorative : elle décide de la sécurité et du coût. Un intranet vit derrière votre authentification interne, souvent sur votre réseau, et son modèle de menace est limité. Un extranet est exposé à Internet et accueille des comptes que vous ne contrôlez pas — il demande une gestion de mots de passe, une limitation des tentatives, une isolation stricte des données entre partenaires, et le coût de ces exigences n’est pas marginal.

L’outil métier se distingue par autre chose : il porte des règles. Un intranet publie de l’information ; un outil métier calcule, valide, refuse, déclenche. C’est cette part de règles qui détermine la charge de développement, pas le nombre d’écrans.

Au cadrage, nous posons donc trois questions : qui se connecte, d’où, et qu’est-ce que le système décide à leur place.

Oui lorsque des interfaces, exports ou API existent. Le cadrage identifie les données à synchroniser, la fréquence, la gestion des erreurs et la source de référence pour chaque information.

La question de la source de référence est celle qui fait échouer les intégrations mal cadrées. Si le client existe dans le CRM et dans l’outil, l’un des deux a raison — et il faut décider lequel, champ par champ. Sans cette décision, les deux systèmes se corrigent mutuellement et les données divergent en quelques semaines.

La gestion des erreurs est l’autre poste sous-estimé. Un échange qui fonctionne quand tout va bien se code vite ; le même avec la reprise après une coupure de l’ERP, la détection des doublons, l’ordre garanti des opérations et une alerte quand la synchronisation s’arrête demande trois à cinq fois plus de travail. C’est ce que nous chiffrons.

Quand l’ERP n’a pas d’interface documentée, un échange de fichiers déposés à intervalle régulier reste une solution honnête. Elle est moins élégante et elle fonctionne depuis vingt ans.

L’authentification peut s’appuyer sur votre annuaire ou votre fournisseur d’identité. Les rôles, permissions et restrictions par périmètre sont définis avec vous puis vérifiés en recette.

En pratique, la connexion unique passe par les protocoles standards — SAML ou OpenID Connect — et s’adosse à ce que vous utilisez déjà : Microsoft Entra, Google Workspace, ou un annuaire interne. Le raccordement prend un à trois jours quand l’accès à la configuration est disponible ; c’est l’obtention de cet accès qui prend parfois trois semaines, et nous le demandons au démarrage plutôt qu’à la veille de la recette.

Les droits se conçoivent par rôle et non par personne, sinon ils deviennent ingérables au premier départ. Nous écrivons une matrice : pour chaque rôle, ce qu’il voit, ce qu’il modifie, ce qu’il valide. Cette matrice est relue par vous avant développement, parce qu’elle contient presque toujours une surprise — un profil qui pouvait faire quelque chose que personne n’avait autorisé.

La vérification se fait côté serveur, pas seulement en masquant un menu.

Non. Le projet peut compléter un ERP, un CRM ou un outil de gestion en couvrant ce qu’ils ne savent pas faire, sans dupliquer une fonction déjà correctement assurée.

Le piège classique est la reconstruction par confort : redévelopper un module qui existe déjà dans l’ERP parce que son interface est ingrate. Le résultat est un second endroit où la même donnée est saisie, et une divergence garantie. Nous préférons améliorer l’accès à l’outil existant, même si c’est moins satisfaisant à présenter.

À l’inverse, trois cas justifient de construire à côté. La fonction n’existe pas dans vos outils. Elle existe mais son coût de licence par utilisateur rend l’ouverture à cent personnes déraisonnable. Ou elle existe et l’éditeur ne permet pas de l’adapter à votre règle, qui est précisément votre avantage.

Le cadrage produit donc une carte : ce qui reste dans les outils en place, ce qui vient dans le nouveau, et les échanges entre les deux. Cette carte tient sur une page et évite des mois de malentendus.

Par des points courts et cadrés : validation des parcours, tests sur un périmètre restreint, retours consignés. La participation améliore l’adoption sans transformer chaque avis en demande d’évolution.

Le format qui fonctionne : trois à cinq utilisateurs représentatifs, deux séances d’une heure par lot, sur l’outil réel et non sur des maquettes. Une séance montre en vingt minutes ce qu’un questionnaire ne révèle pas — l’ordre dans lequel les gens travaillent réellement, les champs qu’ils remplissent en dernier, le tableau qu’ils exportent pour le retravailler ailleurs.

La règle qui protège le calendrier : un retour est une observation, pas une décision. Les observations sont consignées, regroupées, puis arbitrées par le responsable du projet en fin de lot. Sans cette étape, chaque séance ajoute des demandes et le périmètre double sans que personne l’ait voulu.

Ce qui ralentit vraiment un projet n’est pas la participation mais son absence : un outil conçu sans ses utilisateurs est corrigé après la mise en production, quand la correction coûte cinq fois plus.

Oui. Un premier lot peut traiter un processus complet avec les rôles, données et cas d’erreur nécessaires. Les extensions suivantes s’appuient sur un socle déjà éprouvé en conditions réelles.

Le découpage utile suit les processus, pas les écrans. Un lot qui couvre « la demande de congé, de la saisie à la validation par le manager, avec le refus et la modification » est utilisable dès le premier jour. Un lot qui couvre « tous les écrans de saisie sans les validations » ne l’est pas, et il ne produira aucun retour d’usage.

Deux éléments doivent être dans le premier lot même s’ils ne servent pas encore : le modèle de données dans son ensemble, et la gestion des droits. Le premier parce qu’une migration de données déjà saisies coûte cher ; le second parce qu’ouvrir un outil à tous puis le restreindre demande de revoir chaque écran.

Un premier lot représente en général de quinze à trente jours de travail. En dessous, on livre une démonstration ; au-dessus, on perd le bénéfice du retour rapide.

Par un inventaire des sources, un nettoyage, des règles de correspondance, des imports de test puis une reprise contrôlée, avec vérification des volumes, des doublons et des cas particuliers.

La migration se fait au moins trois fois : un import à blanc pour découvrir la réalité des données, un second après nettoyage pour vérifier les règles, et le dernier en production. Chacun produit un rapport comparant les volumes attendus et obtenus, ligne par catégorie. Un écart de deux pour cent qu’on ne s’explique pas doit être compris avant de continuer.

Ce qu’on trouve systématiquement : des champs utilisés pour autre chose que leur nom, des dates au format incohérent selon l’année de saisie, des doublons que personne ne considérait comme tels, et des enregistrements rattachés à des références qui n’existent plus. Le nettoyage n’est pas un travail technique : il demande une décision métier sur chaque catégorie, et c’est vous qui la prenez.

Nous conservons les données d’origine intactes et traçables. Une migration dont on ne peut pas repartir n’est pas une migration.

La maintenance peut être assurée par Novatis ou par votre équipe technique. Les accès, la documentation et les procédures sont transmis pour permettre les deux scénarios sans dépendance imposée.

Ce qui rend les deux scénarios possibles se décide pendant le développement, pas à la livraison : un environnement reproductible depuis le dépôt, des dépendances déclarées avec leurs versions, une procédure de déploiement écrite et rejouée plusieurs fois, et une documentation des règles métier telles qu’elles ont été codées.

Si vous confiez la maintenance à votre équipe, nous prévoyons une passation de deux à quatre demi-journées avec ses développeurs, sur le code et non sur un diaporama. S’ils n’existent pas encore, nous le disons : un outil métier sans personne pour le suivre se dégrade en dix-huit mois, indépendamment de sa qualité initiale.

Si la maintenance nous reste, le contrat dit ce qu’elle couvre, le délai d’intervention selon la gravité, et ce qui est facturé au temps passé. Une évolution fonctionnelle n’est pas de la maintenance, et confondre les deux fait les désaccords.