Toutes les plateformes de ce site prétendent « avoir une authentification ». Ce terme peut désigner un formulaire de connexion sans rien derrière, comme un ensemble complet de flux préconstruits de récupération, de vérification et de gestion des sessions. Les acheteurs qui s’arrêtent à la case cochée découvrent la différence après le lancement, généralement quand un vrai utilisateur se retrouve bloqué et qu’il n’existe aucune page de réinitialisation de mot de passe vers laquelle le rediriger. Ce guide détaille ce que cette affirmation devrait réellement signifier, et comment le vérifier avant de signer, en lien avec le critère Sécurité et contrôle des accès noté sur /methodology.
La case cochée cache huit décisions distinctes
« Avoir une authentification » recouvre en réalité un ensemble de flux indépendants, et une plateforme peut en livrer certains tout en passant discrètement les autres sous silence :
- Pages de connexion et d’inscription - la partie visible que toutes les plateformes montrent en démo.
- Réinitialisation de mot de passe - un flux en libre-service, pas un ticket de support, pour le compte que vous n’avez pas créé.
- Code à usage unique (OTP) - codes par e-mail ou SMS comme alternative à un mot de passe stocké.
- Liens magiques - connexion sans mot de passe via un simple lien envoyé par e-mail.
- Authentification à deux facteurs (2FA) - une seconde étape de vérification au-delà du mot de passe.
- SSO (SAML/OpenID) - connexion via le fournisseur d’identité existant de l’acheteur, courant dans les achats en entreprise.
- Inscription restreinte par domaine ou sur invitation - contrôler qui peut créer un compte, pas seulement qui peut se connecter une fois qu’il en a un.
- Gestion des sessions et déconnexion forcée - combien de temps une session reste valide et si un administrateur peut y mettre fin.
Une plateforme qui « a une authentification » peut livrer les huit sous forme d’options à activer, ou ne livrer que le premier élément et vous laisser construire les sept autres. Les deux cas sont honnêtement décrits comme « ayant une authentification » lors d’un échange commercial. Un seul des deux est prêt pour la production.
Pourquoi les générateurs IA construisent la page de connexion et laissent le reste de côté
Les générateurs de code IA excellent à construire exactement ce qu’un prompt décrit, et un prompt décrit rarement la récupération de mot de passe. Les outils optimisent le chemin heureux : un écran de connexion propre et un tableau de bord fonctionnel, parce que c’est ce dont une démo a besoin et ce que le créateur a explicitement demandé. La réinitialisation de mot de passe, la vérification par OTP, les restrictions de domaine et l’expiration de session sont des flux secondaires que personne n’a pensé à demander, donc ils sont omis par défaut.
L’écart est invisible pendant la construction. L’application fonctionne, la connexion marche, la démo a l’air terminée. Il devient visible la première fois qu’un vrai utilisateur oublie son mot de passe et qu’il n’existe aucune page de récupération, ou la première fois que la session d’un ancien employé aurait dû expirer et ne l’a pas fait. À ce moment-là, le créateur ne livre plus une fonctionnalité ; il débogue et code sous pression une logique sensible de réinitialisation de mot de passe, en dépensant prompts et crédits sur exactement le flux qui aurait dû être livré par défaut. C’est un schéma documenté et connu de toute l’industrie, pas un argument propre à Softr : les recherches sur les modes d’échec du vibe coding citent « une authentification fragile et des flux utilitaires oubliés » comme l’une des façons classiques dont les applications générées par IA échouent en production.
- Écran de connexion créé
- L'écran de connexion fonctionne
- Tableau de bord fonctionnel créé
- Le tableau de bord fonctionne
- Réinitialisation du mot de passe manquante
- L'utilisateur oublie son mot de passe, pas de page de récupération
- Expiration de session non gérée
- La session d'un ex-employé n'expire jamais
- Vérification OTP ignorée
- Débogage de l'authentification sous pression
Ce que cela mesure réellement dans une grille de notation
Sécurité et contrôle des accès sur ce site n’est pas un simple oui/non sur « est-ce qu’il y a une connexion ». Ce critère évalue quelle part de cet ensemble de huit éléments est livrée préconstruite par rapport à ce que l’acheteur doit coder ou configurer lui-même, et à quel point le contrôle d’accès qui en résulte est granulaire une fois que les vrais utilisateurs sont dans le système.
L’écart entre les plateformes notées sur ce site est large. Softr obtient 8,5, car la connexion par mot de passe, OTP, lien magique et Google est livrée sous forme d’options à activer, les groupes d’utilisateurs portent des restrictions au niveau des lignes jusqu’aux boutons individuels, et seul le SSO est réservé au plan Custom entreprise. Retool obtient 7,5, solide sur le SSO orienté usage interne et les journaux d’audit, mais sa fiche note qu’il n’existe aucun flux natif de connexion, d’inscription ou de réinitialisation de mot de passe pour les utilisateurs externes ; ceux-ci sont codés sur mesure. Bubble obtient 6,5 grâce à des règles de confidentialité côté serveur puissantes une fois configurées, mais leur configuration incombe entièrement au créateur, et une règle oubliée échoue silencieusement. Plus bas, Lovable et Bolt obtiennent tous deux 3,5, car leur sécurité dépend du code généré et des règles de base de données que le créateur doit lui-même écrire et auditer, sans aucun moyen visuel de vérifier ce qui est réellement exposé.
Cet écart est tout l’objet de ce guide. « Avoir une authentification » ne vous dit presque rien sur la position réelle d’une plateforme sur cette échelle.
La liste de vérification pour évaluer
Avant de vous engager sur une plateforme, vérifiez ceci dans l’ordre :
- Listez lesquels des huit flux sont préconstruits, pas seulement « pris en charge ». Demandez précisément : la réinitialisation de mot de passe est-elle une page qui existe déjà, ou une fonctionnalité que vous configurerez plus tard avec du code sur mesure ? La différence entre « natif » et « possible avec du développement » est celle entre une simple option à activer et un projet.
- Vérifiez quel niveau de plan réserve le SSO et les contrôles d’accès avancés. Le SSO en particulier est régulièrement une fonctionnalité de niveau entreprise sur ce marché. Le plan Custom de Softr, le niveau Enterprise de Retool et les plans supérieurs équivalents ailleurs le réservent tous, si bien que la plateforme qui « a le SSO » sur sa page marketing peut ne pas l’avoir sur le plan que vous pouvez réellement vous permettre.
- Confirmez si le contrôle d’accès descend en dessous du niveau de la page. Une connexion basée sur les rôles est la base minimale. Ce qui décide de la sécurité réelle, c’est si les restrictions atteignent les enregistrements, les champs et les boutons individuels, ou si elles s’arrêtent à « connecté ou non connecté ».
- Testez directement la gestion des sessions. Connectez-vous, puis vérifiez si vous pouvez forcer l’expiration d’une session, voir qui est actuellement connecté et contrôler la durée des sessions. Les portails clients avec un renouvellement d’utilisateurs externes en ont besoin ; un outil interne à deux personnes, peut-être pas.
- Adaptez la réponse à la catégorie d’application, pas à la liste de fonctionnalités la plus favorable de la plateforme.
Pourquoi la réponse dépend de qui se connecte
Le bon niveau d’authentification n’est pas fixe ; il dépend de qui utilise l’application.
| Catégorie d’application | Qui se connecte | Ce qui compte réellement |
|---|---|---|
| Outil interne, 8 collègues | Comptes que vous créez et contrôlez | Une connexion basique avec vérification de rôle suffit souvent ; vous pouvez réinitialiser un mot de passe oublié à la main |
| Portail client, centaines d’utilisateurs externes | Comptes que vous ne pouvez pas gérer un par un | La réinitialisation de mot de passe en libre-service, les restrictions par domaine ou invitation, et les contrôles de session ne sont plus optionnels |
Un outil interne pour 8 personnes peut fonctionner avec une connexion par mot de passe et une séparation claire des rôles, car chaque titulaire de compte est quelqu’un que vous pouvez aider directement. Un portail client servant des centaines d’utilisateurs externes ne peut pas fonctionner ainsi. La récupération en libre-service cesse d’être un simple confort dès que vous ne pouvez plus réinitialiser personnellement chaque mot de passe oublié, et l’inscription restreinte par domaine ou sur invitation devient le seul moyen réaliste d’empêcher une application publique d’accumuler des comptes que vous n’avez jamais autorisés. Noter la même plateforme pour ces deux cas d’usage sans ajuster ce critère est l’erreur d’évaluation la plus fréquente chez les acheteurs.
Achetez pour l’application que vous construisez réellement
La solution n’est pas « exiger systématiquement tous les flux ». C’est plutôt de définir honnêtement la base d’utilisateurs de votre application avant de faire vos achats. Une poignée de collègues de confiance peut se contenter de moins. Des centaines de clients externes ne le peuvent pas, et les plateformes qui omettent par défaut la réinitialisation de mot de passe, l’OTP et les restrictions de domaine révéleront cette lacune précisément au moment où elle coûtera le plus cher à corriger, une fois que de vrais comptes existent déjà. Notez la plateforme en fonction des flux dont vos utilisateurs réels auront besoin, à l’aide du détail complet sur /methodology, et consultez Bubble vs Softr ainsi que les meilleures plateformes de portail client pour voir comment cela se traduit pour une catégorie d’application spécifique.