Tester la connexion et sécurité

Un datasource conserve la clé d'une vraie base de données — souvent, de production. Cette page couvre les deux versants de cette responsabilité : comment confirmer que la connexion fonctionne avant d'enregistrer, et ce que la plateforme fait (et refuse de faire) avec les identifiants ensuite.

#Tester la connexion

Le bouton Tester la connexion est dans le formulaire de création et dans la fenêtre Modifier la connexion, à côté des actions d'enregistrement :

1. Remplissez les champs de connexion.
2. Cliquez sur Tester la connexion. Le bouton devient Test en cours….
3. La plateforme ouvre une vraie connexion à la base de données, exécute une requête de vérification inoffensive, et ferme la connexion. Rien n'est écrit ni modifié.
4. En cas de succès s'affiche la confirmation « Connexion OK. » ; en cas d'échec, une alerte avec le message renvoyé par le moteur de la base de données — tel quel, parce que c'est lui qui dit quoi corriger.

Deux cas particuliers :

• En modification avec le mot de passe vide, le test utilise le mot de passe enregistré — autrement dit, il teste la connexion telle qu'elle sera après l'enregistrement.
• Sur un SQLite pas encore créé, il n'y a pas de bouton — le fichier n'existe pas encore, et un test à cet endroit ne pourrait que mentir. Il apparaît après l'enregistrement.

#Le test a échoué — et maintenant ?

Le message vient du moteur, donc il varie ; les schémas, non :

Symptôme	Ce qu'il faut vérifier
Cela traîne et finit en timeout	Host et Port corrects ? Le serveur accepte-t-il les connexions depuis la machine où tourne la plateforme (pare-feu, réseau) ?
Erreur d'authentification / login failed	Utilisateur et Mot de passe. Sur certains moteurs, vérifiez aussi si ce compte peut se connecter depuis une autre machine.
Base de données inconnue	Le champ Database contient-il le nom exact de la base à l'intérieur du serveur ?
Erreurs SSL/TLS sur un SQL Server 2008/2012	Activez TLS hérité (ancien SQL Server) — c'est exactement pour cela.
Erreurs de certificat sur d'autres moteurs	Utiliser SSL / Encrypt selon ce que le serveur exige ; sur des serveurs internes avec un certificat maison, Trust server certificate.
Oracle ne trouve pas le service	La Connect string suit-elle host:port/service_name ? Le service_name est-il celui du service, et non le SID ?

#Des identifiants qui ne reviennent jamais à l'écran

Le mot de passe d'un datasource est à écriture unique : il entre dans le formulaire, et à partir de là la plateforme ne le montre plus — à personne, jamais, pas même à celui qui l'a écrit.

• En ouvrant Modifier la connexion, tous les champs arrivent remplis sauf le mot de passe. Le champ s'appelle Mot de passe (vide = conserver) : vide, l'actuel reste ; rempli, il le remplace.
• Il n'existe aucun écran, aucun export ni aucune permission qui renvoie le mot de passe en clair. Si vous le perdez, redéfinissez-le sur le serveur de la base de données et écrivez le nouveau ici.
• Au repos, les identifiants sont chiffrés — comme le disent les formulaires eux-mêmes : « Tout est chiffré au repos. »

#Et quand l'app voyage ?

En exportant une app (Paramètres → Exporter l'app), vous choisissez le sort des secrets :

• Sans secrets (recommandé) — « Les connexions des datasources et les secrets partent vides ». Celui qui importera sur une autre installation remplira à nouveau les identifiants — les mots de passe ne voyagent pas.
• Avec secrets, protégés par une passphrase — les valeurs partent chiffrées avec une passphrase que vous définissez et qui sera demandée à l'import. « Sans la passphrase, les secrets du package sont irrécupérables. »

#Qui peut faire quoi

Action	Profil nécessaire dans l'app
Voir la liste des datasources et utiliser l'app	Développeur
Créer, modifier, renommer, supprimer des datasources	Administrateur
Console SQL, créer/modifier des objets (DDL)	Administrateur

C'est pour cela qu'un développeur peut ne pas voir le bouton Ajouter un datasource ni le menu Modifier la connexion — ce n'est pas une erreur, c'est le profil.

#Tout est enregistré

• Historique de l'app — chaque création, modification, renommage et suppression d'un datasource entre dans l'historique des modifications (« Datasource "crm" créé », « Datasource "crm" modifié », …), avec auteur et date.
• Audit de la plateforme — les mêmes opérations restent dans la piste d'audit du Radar, avec la cible Datasource.
• Console SQL — quand vous exécutez du SQL qui écrit ou modifie (un UPDATE, un DROP…), l'événement est audité avec le type d'opération et une empreinte de la requête — sans le texte du SQL, pour que des données sensibles écrites dans la console ne finissent pas dans le registre.
• Radar → État — la section Connexions aux bases de données montre les connexions configurées dans toutes les apps. Et avec une prudence délibérée : « Cette page ne se connecte d'elle-même à aucune d'entre elles : ce sont des bases de données de production, et ouvrir des connexions à chaque visite est un trafic que personne n'a demandé. »

#Bonnes pratiques

• Compte dédié, privilèges minimaux. Créez dans la base de données un utilisateur rien que pour l'app, avec accès seulement aux tables nécessaires. Tout ce que l'app exécute — APIs, scripts, console — passe par ce compte.
• Pointez les tests sur des données de test. En testant une API qui écrit, la plateforme elle-même avertit : « Le test exécute réellement le pipeline sur les datasources — une mutation effectue de vraies écritures. Vérifiez que vous pointez sur des données de test. »
• Chiffrez la connexion chaque fois que le serveur le permet (Utiliser SSL / Encrypt) — en particulier quand la base de données est sur un autre réseau.
• Des noms qui disent l'environnement. crm et crm-test évitent la pire méprise possible : écrire au bon endroit du mauvais environnement.

#Questions fréquentes

• Keplin me montre-t-il le mot de passe que j'ai enregistré ? Non. Il est à écriture unique — l'alternative est de le remplacer.
• Tester la connexion touche-t-il aux données ? Non. Cela ouvre la connexion, exécute une requête de vérification inoffensive et referme.
• Pourquoi le test passe-t-il mais la requête de l'API échoue-t-elle ? Le test valide la connexion, pas les privilèges sur chaque table. Si le compte ne peut pas lire ou écrire dans une table, c'est sur cette requête que l'erreur apparaît.
• J'ai changé le mot de passe sur le serveur de la base de données — et maintenant ? Les APIs et les scripts commencent à échouer avec une erreur d'authentification. Ouvrez Modifier la connexion, écrivez le nouveau mot de passe et Enregistrer.