Déployer Kantibat sur un parc géré

À qui s'adresse cette page

À l'informaticien qui doit poser Kantibat sur plusieurs postes sans passer devant chacun : service informatique interne, infogéreur, prestataire qui administre le parc d'une entreprise du bâtiment.

Elle est technique et elle est datée. Les paramètres qui y figurent sont ceux qu'on saisit dans une console de déploiement, pas des ordres de grandeur.

Le point qui décide de tout : deux paquets, et ils ne s'installent pas au même endroit

Kantibat est une application Electron livrée sous deux formes. Le choix se fait ici, avant d'ouvrir une console, parce qu'il commande tout le reste.

Si vous administrez un parc, prenez le MSI. Il est fait pour ça : il se pose en silence, sous Program Files, pour tous les comptes du poste, et il ne va jamais chercher une mise à jour derrière votre dos. Sa section est plus bas.

L'installateur .exe, lui, est empaqueté avec Squirrel et se pose dans le profil de l'utilisateur, sans droit d'administrateur. Il convient à l'indépendant et au déploiement Intune en contexte utilisateur. La conséquence n'est pas symétrique, et c'est elle qu'il faut retenir :

• Intune, en contexte utilisateur : oui. Le déploiement fonctionne tel quel, avec les paramètres donnés plus bas.
• Configuration Manager (SCCM) ou Intune en contexte machine : non. Lancé sous le compte SYSTEM, l'installateur se pose dans le profil de SYSTEM : le déploiement est rapporté comme réussi, et aucun utilisateur ne voit l'application.

Un parc administré exclusivement par Configuration Manager n'a donc pas à contourner quoi que ce soit : c'est exactement le cas du MSI.

Configuration requise des postes

Kantibat est une application Electron qui rend du PDF : sans IA, elle est légère. Ce qui fait monter la mémoire, ce sont les plans ouverts en onglets et la définition des A0, jamais le moteur de comptage — il est déterministe et il tient dans le processeur.

Le minimum ne se dédouble pas : c'est le plancher pour faire tourner le produit, que l'IA soit activée ou non. C'est la recommandation qui se sépare en deux, parce que l'IA locale est le seul poste qui change réellement la machine à commander.

Rien d'autre n'est à installer au préalable : ni Node.js, ni moteur de base de données, ni visionneuse tierce. Le convertisseur DWG est livré dans le paquet.

« x64 » désigne les processeurs Intel comme AMD : il n'y a aucune restriction de marque, et un parc de Core i5 ou i7 est la cible normale du produit. Ce qui n'existe pas, c'est un paquet Windows sur ARM.

L'écran compte plus que le processeur. On travaille sur des A0 réduits : un poste de 1920 × 1080 fonctionne, un 2560 × 1440 évite de zoomer en permanence. C'est une appréciation d'usage, pas un prérequis technique.

Si vos utilisateurs activent l'IA locale

L'IA est désactivée par défaut, elle est facultative, et elle n'écrit jamais un chiffre dans un métré — au mieux elle propose un contrôle. Quand elle est activée, le modèle tourne sur le poste : rien ne part chez un tiers, mais il faut la mémoire correspondante. Kantibat retient le plus grand modèle que le matériel détecté supporte, en lisant la mémoire vive ou celle de la carte graphique.

C'est le palier de 16 Go qui débloque le modèle le plus capable sur un poste sans carte graphique dédiée. Les trois modèles sont sous licence Apache 2.0, téléchargés depuis Hugging Face au moment où l'utilisateur l'accepte, et vérifiés par empreinte. Si votre politique interdit ce téléchargement, l'application fonctionne intégralement sans lui.

Les autres plateformes

Un paquet macOS existe (image disque .dmg et archive .zip pour les postes gérés), signé d'un Developer ID et notarisé par Apple, et mis à jour tout seul. Il ne couvre que les Mac à puce Apple Silicon — les Mac Intel ne sont pas servis —, et sa version peut être en retard sur celle de Windows, la construction exigeant un Mac loué à la journée. Un paquet Linux x64 existe également, servi par un dépôt APT signé en OpenPGP qui apporte les versions suivantes par le gestionnaire de paquets du poste ; le .deb seul et l'archive restent disponibles, sans signature ni mise à jour. Une version iOS est prévue en phase 2 du projet et n'existe pas aujourd'hui.

Obtenir le paquet MSI

Le paquet MSI signé est publié sur le canal public, sans compte à ouvrir et sans lien temporaire. La page Installer — parc géré donne ensemble le MSI de la version courante, son empreinte SHA-256 et les codes d'installation destinés aux règles de détection.

Vérifiez avant de déployer, avec l'empreinte publiée à côté du paquet :

Get-FileHash .\Kantibat.msi -Algorithm SHA256

Le paquet porte une signature Authenticode valide, délivrée par Microsoft et horodatée. Le sujet du certificat est CN=KANTIBAT, O=KANTIBAT, L=Suresnes, C=FR : c'est cette identité d'éditeur qu'une règle AppLocker ou App Control peut autoriser (voir plus bas). L'empreinte reste le contrôle exact du fichier téléchargé ; elle complète la signature sans la remplacer.

Figez la version dans votre console. Les liens publiés sont versionnés : conservez l'adresse de la version que vous avez qualifiée, puis remplacez-la seulement après avoir validé la suivante.

Déployer le MSI

Rien de particulier : c'est un MSI ordinaire, et il se comporte comme tel.

msiexec /i Kantibat.msi /qn                    installation silencieuse
msiexec /i Kantibat.msi /qn /l*v pose.log      la même, avec journal détaillé
msiexec /x Kantibat.msi /qn                    désinstallation silencieuse

Une version suivante s'installe par-dessus : rien n'est à désinstaller d'abord, Windows Installer remplace au lieu d'empiler. Les métrés vivent sous %APPDATA%\Kantibat, par utilisateur : ni une montée de version ni une désinstallation n'y touchent.

Un piège, et il ne vient pas de nous. La marche à suivre habituelle veut qu'on accroche la règle de détection au Product Code du MSI. Ici, ne le faites pas : notre chaîne de fabrication en tire un nouveau à chaque construction, si bien qu'une détection fondée dessus se casserait à chaque version publiée. Deux voies tiennent dans le temps :

• Détection par fichier et version — C:\Program Files\Kantibat\Kantibat.exe, version supérieure ou égale à celle déployée. C'est celle que nous recommandons.
• Détection par le code de mise à niveau (UpgradeCode), qui, lui, est fixe et ne bouge pas d'une version à l'autre.

Les deux codes de chaque version sont publiés dans Kantibat.msi.codes.txt, à côté du paquet : vous n'avez pas à ouvrir le MSI pour les lire.

Le poste installé par MSI ne cherche jamais de mise à jour, et ce n'est pas un réglage qu'on pourrait perdre : le paquet n'embarque pas le mécanisme de mise à jour, et l'application le sait d'elle-même. Vous décidez du calendrier ; l'utilisateur ne peut ni l'avancer ni le subir. L'application continue en revanche d'afficher la version publiée à côté de la sienne, et d'écrire sa version au journal à chaque démarrage — de quoi relever les postes en retard depuis votre supervision.

Déploiement par Intune, application Win32

Cette section décrit l'installateur par utilisateur. Pour un parc géré, préférez le MSI ci-dessus.

L'installateur est emballé au format .intunewin avec l'outil de préparation de contenu de Microsoft :

IntuneWinAppUtil.exe -c .\livraison -s Kantibat-Setup.exe -o .\intunewin

L'installation silencieuse et la désinstallation ne sont pas des options découvertes à l'usage : le cycle complet — installation, création des raccourcis, activation, mise à jour, désinstallation propre — est rejoué sur une machine Windows vierge avant la publication d'une version.

Ces deux commandes s'exécutent bien dans la session de l'utilisateur, et %LOCALAPPDATA% y désigne donc son profil. C'est la règle de détection, et elle seule, qui fait exception — voir la section suivante.

La règle de détection s'exécute en compte SYSTEM

C'est le piège classique des applications par utilisateur, et il ne se voit pas à la lecture : même pour une application déployée en contexte utilisateur, Intune évalue la règle de détection sous le compte SYSTEM. Les variables %LOCALAPPDATA% et %APPDATA% y désignent le profil de la machine, pas celui de l'utilisateur. Une détection par chemin de fichier dans le profil rend donc « non installé » sur un poste où l'application tourne — et Intune réinstalle en boucle.

Détecter par le registre de l'utilisateur, où Squirrel écrit son entrée de désinstallation :

La même entrée porte DisplayName, InstallLocation et UninstallString : c'est elle qui fait apparaître Kantibat dans Paramètres → Applications installées, et c'est elle qu'un inventaire logiciel doit relever.

Contrôle d'application : AppLocker et App Control

C'est le point qui décide d'un déploiement sur un parc durci, et il vaut pour toutes les applications Electron installées par Squirrel, pas seulement pour celle-ci.

Les jeux de règles par défaut d'AppLocker et d'App Control for Business (anciennement WDAC) autorisent l'exécution depuis Program Files et Windows, et la refusent depuis les emplacements où un utilisateur standard peut écrire — dont %LOCALAPPDATA%. C'est une protection légitime : c'est là que se pose l'essentiel des logiciels malveillants. Mais c'est aussi exactement là que s'installe une application qui ne demande pas l'administrateur.

Deux réponses, dans cet ordre :

• Programme d'installation géré (managed installer) : l'extension de gestion Intune est déclarée source d'installation autorisée. Windows marque alors les fichiers qu'elle dépose, et ceux-ci s'exécutent sans règle nominative. C'est le mécanisme prévu par Microsoft pour ce cas précis, et il vaut pour tout le catalogue déployé, pas seulement pour Kantibat.
• Règle d'éditeur, fondée sur la signature de l'exécutable plutôt que sur son chemin. Le MSI et l'installateur par utilisateur sont signés par CN=KANTIBAT : la règle peut donc suivre l'éditeur à travers les versions. Une règle de chemin autorisant %LOCALAPPDATA% en entier reviendrait à ouvrir le dossier que la politique cherche à fermer : à éviter.

Chaque livraison est accompagnée de l'empreinte SHA-256 de l'installateur. Elle permet de contrôler exactement ce qui a été téléchargé avant de l'introduire dans le parc.

Ce que le poste envoie sur le réseau

Le métré fonctionne hors ligne et les projets restent sur le poste. L'IA locale traite les plans sur place. Si un utilisateur choisit un fournisseur d'IA distant ou envoie des pièces au support, ces contenus quittent le poste. Les administrateurs peuvent encadrer ces usages et leurs flux réseau selon leur politique interne ; les échanges de compte, de licence et de mise à jour restent distincts.

Les connexions sortantes réellement émises, à autoriser en proxy ou en filtrage d'URL :

Un poste privé de ces accès reste utilisable pour le métré ; il perd la mise à jour automatique et la gestion du compte, et se licencie alors par le parcours hors réseau décrit plus bas.

L'assistance visuelle facultative s'exécute sur le poste. Aucun fournisseur en ligne n'est proposé, et l'adresse d'un moteur local est bornée à la boucle locale : une adresse extérieure est refusée avec son motif.

Où vivent les données, et ce que ça change en VDI

Les métrés, la licence et la configuration sont écrits sous %APPDATA%\Kantibat, dans le profil de l'utilisateur — donc dans la partie itinérante du profil.

Kantibat est conçu pour un poste de travail physique attribué à une personne. Il fonctionne sur bureau virtuel, mais ce n'est pas la configuration sur laquelle il est éprouvé : à valider sur un poste pilote avant d'engager un déploiement.

La désinstallation retire l'application et laisse %APPDATA%\Kantibat en place, pour qu'une réinstallation ou une mise à jour ne perde aucun métré. Une remise à zéro complète suppose de supprimer ce dossier explicitement.

Sauvegarder les métrés sur un parc

Kantibat n'envoie rien nulle part : il n'existe aucun stockage central des projets, aucune console d'administration, et aucune sauvegarde côté éditeur. C'est la contrepartie assumée d'un logiciel qui travaille hors ligne — et cela veut dire que la sauvegarde des métrés est une politique de votre parc, pas un réglage du produit.

Le produit fournit ce qu'il faut pour que votre politique existante la prenne en charge : une archive datée, produite dans un dossier que vous désignez.

Deux choses à sauvegarder, et elles ne sont pas au même endroit

Comment la brancher sur votre sauvegarde

La sauvegarde automatique est désactivée par défaut. Une fois un dossier désigné dans Paramètres → Sauvegarde, elle écrit ses archives à l'échéance choisie, et un clic suffit à en produire une à la demande.

La destination est un dossier local, jamais un service : faites-le pointer sur le OneDrive, le SharePoint ou le Drive déjà installé sur le poste. La synchronisation appartient alors à votre agent, sous votre contrat ; le logiciel n'ouvre aucune connexion sortante pour cela. Un dossier sur un partage réseau sauvegardé par vos soins fonctionne tout aussi bien.

La rotation conserve 7 archives quotidiennes et 4 hebdomadaires, et ne purge jamais la plus récente. Elle ne touche que les fichiers portant le nom produit par le logiciel : vos propres fichiers dans ce dossier ne risquent rien. Si votre politique exige un historique plus long, c'est votre sauvegarde du dossier d'archives qui le fournit, pas la rotation.

Restaurer

La restauration est destructive : elle remplace les métrés du poste. Le logiciel la fait confirmer, produit une sauvegarde de l'état actuel avant de l'appliquer, et l'applique au démarrage suivant — la base ne peut pas être remplacée pendant qu'elle est ouverte. Prévoyez donc un redémarrage de l'application, pas une reprise instantanée.

Ce qu'il faut retenir pour un parc

• Une politique par poste : chaque utilisateur porte ses métrés et ses archives. Sur trois sièges, c'est trivial ; sur vingt postes, c'est le même réglage à poser vingt fois.
• Un poste réinstallé sans archive perd tout — la désinstallation, elle, laisse %APPDATA%\Kantibat en place.
• Rien à ouvrir dans le pare-feu : la sauvegarde est un fichier écrit sur un disque.

Licences sur un parc : masters, sièges et postes hors réseau

Une licence est liée à l'empreinte du poste, dérivée de l'identifiant machine de Windows. Trois conséquences pour un parc :

• Image master. Un déploiement d'image sans sysprep /generalize laisse le même identifiant machine sur tous les postes issus de l'image, donc la même empreinte. À vérifier sur la chaîne de masterisation avant de commander les licences.
• Stratégie fermant la lecture du registre. L'application bascule alors sur un identifiant de repli, moins discriminant : deux postes clonés portant le même nom d'hôte peuvent le partager.
• Réinstallation de Windows. L'identifiant machine change ; le poste demande une nouvelle licence, émise avec son nouveau code.

Le chemin recommandé sur un parc n'exige aucune distribution de fichier de licence : l'entreprise souscrit un abonnement à plusieurs sièges, l'utilisateur ouvre Kantibat et se connecte au compte de l'entreprise — la connexion Microsoft convient — et le poste réclame et installe sa licence tout seul. Il n'y a ni code à collecter, ni fichier à envoyer, ni geste d'administrateur.

Pour un poste destiné à travailler sans réseau — un chantier, un sous-sol, un site isolé —, il faut une connexion une seule fois, à la première ouverture, pour rattacher le poste au compte et installer sa licence. Ensuite, plus aucune : la licence est un fichier signé que l'application vérifie sur le poste, et le métré fonctionne entièrement hors ligne.

Antivirus et EDR

Deux comportements légitimes de l'application peuvent attirer l'attention d'une solution de détection, et méritent d'être connus avant le déploiement plutôt que découverts un mardi matin :

• L'application démarre un service local, à l'écoute sur 127.0.0.1 uniquement, sur un port tiré au hasard et protégé par un jeton de session. Il ne reçoit aucune connexion venue de l'extérieur du poste.
• L'assistance visuelle facultative repose sur un moteur exécutable natif livré à côté de l'application, qui charge un modèle en mémoire. Le profil d'exécution ressemble à celui d'un logiciel de calcul, pas à celui d'un utilitaire de bureau.

Aucun de ces deux points n'exige d'exclusion par défaut. Si la politique du parc en réclame une, elle porte sur le dossier d'installation de l'application, jamais sur le profil utilisateur entier.

Clés d'accès (passkeys) : ce qu'il faut activer pour vos utilisateurs

Kantibat propose à ses utilisateurs de se connecter par clé d'accès — empreinte, reconnaissance du visage ou code Windows Hello, au lieu d'un mot de passe. La connexion se fait chez Google ou chez Microsoft, jamais chez nous : Kantibat ne crée aucune clé d'accès et n'en conserve aucune. Il ouvre la page du fournisseur, et c'est tout.

Conséquence directe, et c'est la raison de cette section : sur un compte Microsoft professionnel, la possibilité dépend entièrement de vous. Un utilisateur dont le locataire ne l'autorise pas ne verra rien, quoi que fasse l'application — et conclura le plus souvent que le logiciel est en cause.

Compte Microsoft professionnel (Microsoft Entra ID)

Trois réglages vous appartiennent, et il en manque un seul pour que l'utilisateur ne puisse rien enregistrer :

Deux points qui surprennent en recette, et qui ne viennent pas de Kantibat :

• Une authentification multifacteur de moins de cinq minutes est exigée au moment où l'utilisateur enregistre sa clé. Passé ce délai, l'enregistrement échoue sans dire pourquoi.
• Les comptes invités (B2B) ne peuvent pas enregistrer de clé d'accès, quelle que soit la stratégie du locataire qui les héberge.

Aucune licence payante n'entre en jeu : la méthode est disponible dans toutes les éditions d'Entra ID, y compris gratuite. Quand cela ne fonctionne pas, c'est une question de stratégie, jamais de facturation. La marche à suivre complète est décrite par Microsoft : activer les clés d'accès (FIDO2) dans Microsoft Entra ID.

Une fois ces réglages posés, l'utilisateur enregistre sa clé sur mysignins.microsoft.com/security-info, puis s'en sert pour entrer dans Kantibat comme ailleurs.

Compte Microsoft personnel, compte Google

Rien à faire de votre côté : l'utilisateur crée sa clé lui-même depuis les réglages de sécurité de son compte, et l'application l'y emmène en un clic.

Si vous préférez ne pas l'autoriser

Il n'y a rien à désactiver dans Kantibat, et rien à bloquer sur le poste : sans stratégie de votre part, la clé d'accès n'existe pas pour vos utilisateurs, et la connexion se fait par mot de passe comme aujourd'hui. Le mot de passe n'est jamais retiré.

Ce que Kantibat ne propose pas

Écrit ici pour éviter de le découvrir en cours de projet :

• Pas de paquet MSIX. Le paquet MSI existe, lui, et couvre l'installation par machine sous Program Files — voir plus haut.
• Pas de console d'administration. Vous voyez qui est équipé, vous ne pilotez pas la configuration des machines depuis chez nous — et vous ne voyez pas les métrés de vos équipes. Ce qui se pilote se pilote par stratégie de groupe : le modèle d'administration Kantibat.admx couvre la sauvegarde (dossier, périodicité, rétention) et la coupure de la mise à jour automatique, sous HKLM\SOFTWARE\Policies\Kantibat. Il se dépose dans le magasin central du domaine, une fois pour toutes, et vaut pour les deux formes d'installation.
• Pas de paquet pour les Mac Intel. Windows 10 et 11 en 64 bits sont la plateforme de référence ; le paquet macOS, signé et notarisé, ne sert que les Mac à puce Apple Silicon ; un paquet Linux x64 existe, servi par un dépôt APT signé.

Ces manques ne sont pas des oublis : ce sont des choix, et ils se rediscutent. Un parc géré qui aurait besoin d'un paquet par machine ou d'un calendrier de mise à jour maîtrisé peut nous le demander — c'est le genre de besoin qui justifie un développement, et nous préférons le savoir avant qu'une DSI se heurte au produit tel qu'il est.