Le contrôle du client, expliqué avec précision.

Vos comptes. L’accès minimal.

Les implémentations de production sont conçues pour des comptes détenus par le client et des identifiants contrôlés par le client. Nous convenons des identités qui peuvent lire, rédiger, valider et exécuter ; un large accès administrateur n’est pas la norme.

Les autorisations d’intégration, les conditions des prestataires et les exigences de localisation des données sont vérifiées lors du cadrage. Le nom d’une plateforme sur ce site ne garantit pas la compatibilité avec chaque politique de tenant ou chaque abonnement.

• Identité de connexion approuvée et responsable désigné chez le client
• Autorisations délimitées pour les sources et les destinations
• Secrets côté serveur, sans identifiants dans les prompts ni dans le code client public
• Responsabilités de révocation et de remise documentées

Sources approuvées, chemins de données explicites.

Le périmètre du workflow définit quelles données sont nécessaires, quels systèmes les reçoivent et quels prestataires les traitent. La conservation, la journalisation et les exigences transfrontalières sont des décisions propres au client, pas des hypothèses fondées sur l’implantation suisse d’AIFAB.

Les autorisations des sources doivent continuer à s’appliquer lorsque l’information est récupérée et présentée. Les données sensibles, les décisions réglementées ou les exigences sectorielles requièrent une revue explicite avant l’implémentation.

Évaluer un déploiement hébergé en Suisse.

Une implantation suisse ne prouve pas à elle seule la résidence des données. Un déploiement envisagé sous contrôle du client nécessite des preuves sur toute la chaîne de traitement avant de pouvoir être proposé comme option validée.

Une architecture de référence à poids ouverts hébergée en Suisse reste non validée. L’évaluation doit couvrir :

• Hébergement suisse vérifié et propriété du compte
• Stockage, journaux, sauvegardes, télémétrie et accès de support documentés
• Preuve réseau qu'aucune sortie non approuvée vers un fournisseur de modèles n'a lieu
• Contrôles équivalents de validation, de repli et de réception
• Revue juridique et de protection des données des prestataires et responsabilités réels

Une validation autorise une action définie.

Une revue doit montrer les preuves, le changement proposé et ce qui se passera ensuite. L’envoi, les dépenses, la réception et les modifications sensibles de systèmes exigent l’autorité convenue pour cette action précise.

Valider une revue de document ou un guide de processus ne valide ni un contrat, ni un achat, ni un octroi d’accès. Les rejeux et les entrées modifiées ne doivent pas hériter d’une validation issue d’un résultat sans rapport.

Se préparer aux échecs avant la mise en service.

La réception couvre les entrées invalides, l’ambiguïté, les sources manquantes et les intégrations indisponibles. La journalisation doit rendre un échec diagnosticable sans copier inutilement des données sensibles.

Avant la production, la surveillance, l’escalade, la reprise et le retour à une version antérieure sont convenus. Réessayer une demande ne doit pas dupliquer une action à conséquences. Un retour arrière ne peut pas annuler automatiquement un e-mail déjà envoyé ni un autre effet externe irréversible.

• Configuration et instructions versionnées
• Un parcours de reprise testé et un responsable des incidents nommé
• Une couverture de support définie plutôt qu’une promesse implicite de 24/7
• Mises à jour des dépendances et contrôles de régression avant la mise en service

Le Red Button : une pause détenue par le client avec un parcours manuel.

AIFAB conçoit un contrôle attribué au client qui retient les nouveaux effets automatisés une fois la pause confirmée. Le travail en attente conserve son état, et les nouveaux cas suivent le parcours manuel documenté jusqu’à ce qu’une personne autorisée rétablisse le fonctionnement contrôlé.

Les cinq démonstrations locales exposent ce contrôle et montrent que le rejeu, les changements de scénario et le changement de workflow ne l’annulent pas silencieusement. Une implémentation client a tout de même besoin de preuves de réception propres à ses systèmes : une pause ne peut pas rappeler un e-mail ou une autre action externe déjà terminée.

• Autorité de pause attribuée par le client
• Nouveaux effets automatisés maintenus à la limite de contrôle convenue
• Traitement manuel, responsabilité et état en attente préservés
• Reprise explicitement autorisée
• Événements de contrôle délimités, sans données métier

Ce que ce site web fait aujourd'hui.

Les cinq démonstrations publiques s’exécutent localement avec des jeux de données synthétiques. Il n’y a ni téléversement de documents, ni appel de modèle en direct, ni connexion à des systèmes clients, ni action opérationnelle.

L’application sert les polices localement. La préférence d’affichage utilise le stockage local. Le Workflow Fit Checker et le ROI Calculator s’exécutent localement ; la remise structurée facultative d’un résultat et les informations d’attribution délimitées utilisent le stockage de session de l’onglet pendant 30 minutes au maximum. Aucune description de tâche en texte libre ni coordonnée n’y est enregistrée.

Les points de terminaison de contact et d’envoi de résultats valident les entrées et se ferment lorsque l’envoi ou la protection de débit partagée est indisponible. Resend assure l’envoi d’e-mails demandé et une ressource Upstash Redis applique la protection partagée contre les abus. L’application ne tient pas de base de données des demandes. Les services d’analyse facultatifs ne sont pas actifs au lancement.

Le site est servi en HTTPS avec HSTS, une Content Security Policy qui bloque les scripts distants, les frames et eval, une protection contre le MIME sniffing et une politique de référent restrictive. Les scripts et styles en ligne restent autorisés pour le rendu statique.

Signaler un problème de sécurité.

Utilisez l'option Rapport de sécurité dans le formulaire de contact protégé avec une description concise, la page ou le service concerné et un moyen sûr de vous contacter. Veuillez ne pas inclure de mots de passe, de jetons d'accès, de données client ou de code d'exploitation dans le premier message.

AIFAB accusera réception du signalement, conviendra si nécessaire d'un canal sécurisé et coordonnera la validation et la correction. Ne réalisez aucun test sur les systèmes de clients et n'accédez pas à des données qui ne vous appartiennent pas.