Aucun appel sortant
Le serveur Plannava n'émet aucune requête vers Internet. Vérifié dans le code : pas un client HTTP, pas une URL externe.
Souveraineté et sécurité
Vos projets restent chez vous.
Plannava fonctionne sans aucun service externe. Pas de cloud tiers obligatoire, pas d'authentification déléguée, aucun appel sortant, aucune télémétrie. La même application s'utilise en ligne ou s'installe sur vos serveurs, complète dans les deux cas.
Quatre engagements
Ce que nous ne faisons pas avec vos données.
Ces quatre lignes ne sont pas des intentions. Chacune correspond à une absence vérifiée dans le code, et une absence se vérifie mieux qu'une promesse.
Aucune télémétrie
Ni mesure d'usage, ni traceur d'erreurs, ni outil d'analyse. Rien ne quitte votre instance, pas même un compteur anonyme.
Aucun compte de service tiers
Sept paramètres suffisent à faire fonctionner l'ensemble, dont l'adresse de votre base de données. Il n'y a pas de huitième ligne cachée.
Aucune surveillance des personnes
Les indicateurs du produit portent sur les projets et les flux de travail, jamais sur la performance individuelle. Ce n'est pas un réglage, c'est ce que le produit sait faire.
Les mécanismes
La séparation entre clients.
C'est la garantie sur laquelle repose tout le reste, et c'est celle où nous avons le plus investi. Dans un service partagé, la séparation tient d'ordinaire à la discipline : chaque requête doit porter la marque du client. Une discipline ne survit pas au temps, parce que la requête suivante sera écrite par quelqu'un d'autre, un autre jour.
Une garde mécanique
Elle vit à l'intérieur de la couche de données et inspecte chaque requête, sans exception. Ce n'est pas une revue de code, c'est un mécanisme d'exécution.
Elle refuse, elle ne corrige pas
C'est le choix central. Une garde qui ajouterait silencieusement le filtre manquant produirait un logiciel qui fonctionne avec un code faux. Le jour où ce rattrapage cesserait, la séparation s'ouvrirait sans que personne n'ait rien changé. La nôtre fait échouer la requête et nomme le fichier et la ligne fautifs.
Elle ne se laisse pas convaincre
Elle reconnaît la marque du client posée directement, ou posée à travers une relation elle-même vérifiée sur deux niveaux. Dans une alternative, elle n'accepte que si toutes les branches sont vérifiées. Et elle refuse de considérer qu'un identifiant technique seul vaut preuve d'appartenance.
Deux exceptions, nommées
Il y en a deux dans tout le produit, toutes deux dans la connexion, où le client n'est pas encore connu puisque c'est justement ce que l'authentification établit.
La liste est dérivée, jamais tenue à la main
Les quarante-deux tables concernées sont dérivées du schéma. Une table nouvelle est couverte le jour où elle naît, sans que personne ait à y penser.
Une seule requête en SQL direct
Un verrou technique qui ne lit aucune donnée. Toute nouvelle requête en SQL direct non déclarée fait échouer la construction.
Aux frontières
Une ressource appartenant à un autre client répond « introuvable » et jamais « interdit ». Un refus explicite confirmerait son existence.
Authentification et accès
Ce qu'un attaquant ne peut pas faire.
Quatre mécanismes que l'on trouve rarement réunis, et dont trois se voient seulement quand on essaie de les mettre en défaut.
Aucune énumération de comptes
Un courriel inconnu et un mot de passe faux produisent le même message, et surtout le même temps de réponse : une comparaison factice s'exécute quand aucun compte n'existe. Sans cette précaution, on peut constituer la liste de vos utilisateurs sans jamais entrer.
Le jeton de session hors du navigateur
Il est déposé dans un cookie inaccessible au JavaScript, transmis uniquement en HTTPS en production, et restreint au site. Une faille d'injection de script dans une page ne permettrait pas de voler une session.
Votre API n'a pas besoin d'être exposée
Le navigateur ne dialogue jamais directement avec le serveur applicatif. La couche web relaie les appels côté serveur, et le cœur applicatif peut rester sur un réseau privé.
Des droits appliqués champ par champ
Deux étages, un rôle à l'échelle de l'instance et un rôle par projet. Le code d'un projet et la désignation de son chef relèvent d'un manager, la conduite du projet relève de son chef, un lecteur ne peut rien écrire.
Les mots de passe sont hachés
Stockés en bcrypt, ils ne sont jamais lisibles, y compris par nous. Il n'y a pas de procédure interne qui permettrait de les lire.
La visibilité est bornée par portefeuille
Et la cloison vit dans les requêtes, pas seulement dans l'affichage. Masquer une ligne à l'écran n'est pas la protéger.
Les pièces jointes
Les fichiers que vos équipes déposent.
Les pièces jointes sont l'une des voies d'attaque les plus classiques. Trois décisions les ferment, et deux d'entre elles ferment le problème plutôt que de le filtrer.
Le nom du fichier n'atteint jamais le disque
Sur le stockage, la pièce porte l'identifiant de sa ligne en base, sans extension, dans un dossier dérivé de votre espace client. Les attaques par chemin détourné ne sont donc pas filtrées, elles sont structurellement impossibles, puisque aucun caractère fourni ne participe au chemin.
Le type annoncé n'est jamais cru
Une pièce ne s'affiche dans le navigateur que si ses premiers octets portent la signature d'une image véritable. Tout le reste part en téléchargement neutre. Un exécutable renommé en point png ne trompe pas cette vérification, et le format SVG, vecteur habituel d'injection de script par image, ne peut structurellement pas obtenir l'autorisation d'affichage.
Les extensions exécutables sont refusées
À l'entrée, et deux plafonds distincts protègent la taille du fichier et la mémoire du serveur.
La suppression supprime vraiment
Effacer un projet efface aussi ses fichiers sur le disque. Aucune donnée ne reste à traîner dans un dossier que personne ne regarde plus.
Le stockage est le vôtre
Il passe par une interface interne. Un stockage objet de votre choix, S3 ou MinIO, peut lui être substitué sans modifier l'application.
Notre méthode
Comment nous savons que tout cela est vrai.
Un dossier de sécurité vaut ce que vaut la méthode qui le produit. Voici la nôtre, et elle est inhabituelle.
Une protection se voit échouer
Écrire une garde ne prouve rien. La seule preuve qu'elle protège est de la mettre en défaut volontairement et de constater qu'elle se déclenche. Cette exigence est inscrite dans nos règles de développement, et elle a payé : en deux jours elle a révélé une garde qui affichait vert sans rien protéger, et un compteur qui manquait six familles de requêtes sur dix. Deux erreurs qu'aucune relecture n'aurait montrées.
Nos compteurs disent avec quel instrument
Chaque chiffre publié porte l'empreinte de l'outil qui l'a mesuré. Quand nous corrigeons l'outil et qu'un nombre augmente, on peut distinguer « le produit s'est dégradé » de « nous voyons mieux ». Aucun tableau de bord ordinaire ne permet cette distinction.
Cent onze vérifications, à chaque livraison
Elles s'exécutent sur deux bases de données distinctes. La séparation entre clients y est éprouvée par sa sévérité : une requête sans marque de client doit échouer, et une requête correcte doit passer. Nous comptons aussi ce qui reste à faire, et ce compteur ne peut que descendre : une livraison qui le ferait remonter est refusée automatiquement.
En ligne ou chez vous
Le même produit, et c'est structurel.
L'installation sur vos serveurs n'est pas une version amoindrie. Elle est possible parce que rien dans le produit ne dépend d'un service extérieur : les fichiers vivent sur votre disque, la recherche s'exécute dans votre base, les polices sont servies par l'application, et rien n'émet vers l'extérieur. Vous choisissez donc où vivent vos données, sans changer de logiciel, sans perdre de fonction, et sans dépendre de notre disponibilité.
Le dossier complet
Nous répondons aux questionnaires de sécurité.
Et nous acceptons un audit de code ou un test d'intrusion mené par le tiers de votre choix. Le dossier remis à votre direction informatique va plus loin que cette page : il nomme aussi ce qui n'est pas encore en place, avec son rang dans notre programme. Nous préférons une trajectoire lisible à un dossier qui promet.
Questions fréquentes
Ce que les directions informatiques nous demandent.
Le produit installé chez nous est-il bridé ?
Non. Aucune fonction n'est désactivée dans la version locale, et ce n'est pas une promesse commerciale : c'est structurel. Rien dans le produit ne dépend d'un service extérieur, donc il n'y a rien à retirer quand il change de serveur.
Plannava envoie-t-il des données vers vos serveurs ?
Non. Le serveur Plannava n'émet aucune requête vers Internet. C'est vérifié dans le code : pas un client HTTP, pas une URL externe. Ni télémétrie, ni traceur d'erreurs, ni mesure d'usage.
Comment garantissez-vous qu'un client ne voit pas les données d'un autre ?
Par une garde mécanique placée dans la couche de données, qui inspecte chaque requête et la fait échouer si la preuve d'appartenance manque. Elle refuse au lieu de corriger, parce qu'une garde qui corrige produit un logiciel qui fonctionne avec un code faux. Il y a deux exceptions dans tout le produit, toutes deux dans la connexion, et elles sont nommées.
Acceptez-vous un audit externe ?
Oui. Nous répondons aux questionnaires de sécurité, et nous acceptons un audit de code ou un test d'intrusion mené par le tiers de votre choix.
Le chiffrement des données est-il assuré ?
Le chiffrement du transport et le chiffrement au repos relèvent de votre infrastructure d'accueil, passerelle HTTPS et base de données. Nous fournissons les prérequis correspondants. Les mots de passe, eux, sont hachés par l'application et ne sont lisibles par personne, nous compris.
Voyez-le tourner sur vos projets.
Une démonstration dure quarante-cinq minutes, sur vos cas réels, sans diaporama. Le dossier de sécurité complet vous est remis à cette occasion.