FAQ : Informatique

L’application Lokad est une application web fournie en tant que SaaS (Software as a Service). Le but de Lokad est de fournir des analyses prédictives afin d’optimiser la supply chain (meilleurs stocks, meilleurs prix, etc.). L’application Lokad est conçue comme une couche analytique qui fonctionne aux côtés des systèmes transactionnels (ERP, WMS, CRM, etc.). Elle est proposée avec un abonnement mensuel forfaitaire qui regroupe généralement l’application elle-même avec des services professionnels. Ces services professionnels, fournis par les ingénieurs de Lokad (Supply Chain Scientists), éliminent presque entièrement le besoin de support technique de la part du service informatique lui-même pour ce périmètre. La seule contribution attendue du service informatique est la configuration d’un pipeline de données qui envoie des fichiers plats (par SFTP ou FTPS) à Lokad, et potentiellement la réintégration des résultats générés.

Public cible : Le service informatique
Dernière modification : 30 novembre 2023

Aperçu technique

L’application Lokad est multilocataire. Chaque locataire (c’est-à-dire le compte client) dispose de son propre système de fichiers dédié et de son propre référentiel de code. Le système de fichiers est accessible via FTPS, SFTP et une interface web. Ce système de fichiers est conçu pour les fichiers plats volumineux (jusqu’à 100 Go par fichier) et dispose d’une fonctionnalité de versioning des données (comme Git). Le référentiel de code est utilisé pour héberger les scripts Envision. Envision est un DSL (Domain Specific programming Language) propriétaire développé par Lokad. Ce DSL est fortement spécialisé pour les cas d’utilisation d’optimisation prédictive. Les scripts Envision sont utilisés pour effectuer les analyses numériques de base (y compris les algorithmes d’apprentissage automatique, les solveurs, …) et pour générer des tableaux de bord riches en données.

L’application est redéployée intégralement tous les mardis entre 10h00 et 14h00 (heure de Paris). Le temps d’arrêt est généralement inférieur à 5 minutes. Lokad prend en charge l’ensemble des problématiques de versioning.

Le service informatique n’est pas censé acquérir de compétence spécifique avec la pile technologique de Lokad. Cependant, si vous êtes curieux, il existe une documentation technique complète.

Aperçu de la contribution du service informatique

Nous attendons du service informatique qu’il mette en place un pipeline de données qui envoie une courte série d’extractions de fichiers plats pertinents vers Lokad par SFTP ou FTPS. Les extractions sont effectuées sur les systèmes transactionnels (par exemple, ERP). Nous avons une forte préférence pour les extractions de tables brutes (sans filtre, sans jointure, sans transformation), ce qui nécessite un effort minimal. Du point de vue de l’ETL, nous ne demandons que la partie ‘E’ (extraction) sous sa forme la plus simple (copie simple). En termes de format, Lokad est compatible avec tous les fichiers plats tabulaires raisonnablement structurés.

Le pipeline de données doit fonctionner au moins une fois par jour et être entièrement automatisé. La charge de travail pour le service informatique dépend de l’étendue de l’extraction des données (quels systèmes ? quelles tables ?). Cependant, en règle générale, la configuration du pipeline de données nécessite généralement environ 15 à 45 jours-personnes, même pour les grandes entreprises. Une fois le pipeline de données en place, Lokad ne nécessite généralement qu’un suivi minimal de la part du service informatique, ce qui se fait généralement avec 1 ou 2 jours-personnes par mois.

Aperçu de la sécurité

L’application est hébergée dans les centres de données Microsoft Azure situés dans l’UE. Nous ne traitons aucune donnée personnelle, car nous n’avons pas besoin de telles données pour fonctionner. Lors de l’établissement de l’étendue de l’extraction des données, nous excluons toute colonne ou champ pouvant contenir des données personnelles.

Pour l’authentification, notre préférence va à SAML. Nous recommandons vivement aux utilisateurs d’accéder à Lokad via une identité fédérée telle que Azure Active Directory, Office 365 ou Google Workspace. Cela élimine tous les problèmes liés aux mots de passe.

Sur demande, des audits de sécurité et des tests de pénétration peuvent être effectués par nos clients. Les détails dépendent des accords négociés.

Pour plus de détails, consultez Sécurité chez Lokad.

Aperçu de la chronologie

La Supply Chain Quantitative est plus un voyage qu’une fin en soi. Cependant, en même temps, les responsables de la supply chain qui engagent leur entreprise dans une initiative de Supply Chain Quantitative ont besoin de visibilité en ce qui concerne la chronologie du projet. Bien que des retours positifs puissent être obtenus en quelques mois, il faut souvent jusqu’à deux ans pour exploiter pleinement le potentiel de la Supply Chain Quantitative. Dans la suite, nous présentons un aperçu d’une chronologie typique associée à une initiative de Supply Chain Quantitative pour une entreprise de taille moyenne. Pour les grandes entreprises, il faut s’attendre à ce que les délais soient deux fois plus longs.

Lancement du projet : Les représentants des deux parties se présentent mutuellement et planifient des réunions hebdomadaires. Ces réunions hebdomadaires se poursuivront jusqu’à ce que la phase de production soit atteinte. Le Supply Chain Scientist présente les différentes phases de mise en œuvre et les différents livrables que le client peut attendre. Le reste de l’appel est consacré à l’examen de divers détails de la supply chain et des caractéristiques informatiques de l’intégration. Après l’appel, un résumé documentant les aspects organisationnels du projet est produit et envoyé au client.

Spécifications des données : Peu de temps après la réunion de lancement, le Supply Chain Scientist produit les spécifications des données requises pour la mise en œuvre du projet. Ces spécifications sont examinées et validées avec le client. En particulier, ce document doit définir les données à extraire des systèmes informatiques du client. En règle générale, l’extraction doit rester aussi proche que possible des données d’origine telles qu’elles existent dans les systèmes informatiques du client.

1ère mise à jour des données : Après avoir validé les spécifications, le premier ensemble de données est téléchargé sur les serveurs de Lokad par le client. Généralement, à ce stade, le téléchargement n’est pas encore effectué via un processus automatisé, car plusieurs tentatives sont généralement nécessaires pour établir un consensus sur les détails des spécifications des données.

Validation des données : Le Supply Chain Scientist effectue une enquête approfondie sur le contenu de l’ensemble de données du client. En particulier, des vérifications de cohérence sont introduites pour surveiller la qualité des données selon plusieurs critères. L’objectif est de s’assurer que 1) l’ensemble de données est correctement actualisé par le processus de téléchargement, 2) l’ensemble de données reflète correctement la réalité de l’entreprise et 3) l’ensemble de données est cohérent et suffisamment complet pour les besoins d’optimisation de la supply chain.

En termes de livrables, pendant cette phase, le Supply Chain Scientist fournit au client différents tableaux de bord qui évaluent la santé des données. Ces tableaux de bord peuvent être utilisés par le client même à des fins qui dépassent l’initiative de la Supply Chain Quantitative elle-même - dans le cadre de leur processus interne d’assurance qualité des données, par exemple.

Audit en cours de projet : 6 semaines après le lancement initial, une réunion est organisée pour évaluer l’état d’avancement du projet. L’objectif de cet “audit” est de résoudre, le plus tôt possible, les problèmes qui peuvent survenir pendant la mise en œuvre, en particulier ceux qui pourraient retarder la phase de production. Chez Lokad, cet “audit” consiste en un échange entre le Supply Chain Scientist et le client, basé sur une liste de contrôle qui est communiquée au client à l’avance par le Supply Chain Scientist, juste après la réunion de lancement.

Automatisation du téléchargement : Une fois que les deux parties ont validé la qualité globale de l’ensemble de données qui a été téléchargé jusqu’à présent, le client met en place un processus automatisé qui transfère leur ensemble de données à Lokad régulièrement - idéalement tous les jours. En même temps, du côté de Lokad, la logique de santé des données - avec ses multiples vérifications - est programmée pour être actualisée après chaque téléchargement.

Mise en place de l’optimisation : À partir de ce moment, le Supply Chain Scientist dispose de tous les ingrédients nécessaires pour mettre en œuvre l’optimisation des décisions qui ont été convenues avec le client précédemment. Par conséquent, il met en place des scripts pour générer différentes sorties quantitatives : suggestions d’achat opérationnelles, suggestions de distribution, etc. Les chiffres produits par ces scripts peuvent être visualisés sous forme de tableaux de bord. À ce stade, ces tableaux de bord ne représentent qu’une version préliminaire des tableaux de bord finaux et doivent être révisés avec le client.

Retours et ajustements : Les demandes du client visant à apporter des modifications ou à “ajuster” les différentes sorties conduisent généralement à un ajustement des scripts écrits par le Supply Chain Scientist. Il existe de nombreux paramètres et méthodes qui peuvent être adoptés pour aligner de manière adéquate les caractéristiques de la supply chain optimisée avec la logique d’optimisation. Lorsque la méthodologie elle-même revêt une importance stratégique pour le client, cela est explicitement discuté entre le client et le Supply Chain Scientist.

Production : Après plusieurs cycles d’ajustement et de révision, le client atteint un stade où il fait confiance à la logique mise en œuvre par le Supply Chain Scientist. À ce stade, le client peut commencer à utiliser le service en production, c’est-à-dire qu’il peut exécuter directement les décisions de la supply chain telles qu’elles ont été calculées à l’origine par le logiciel. Lorsque le client valide que la solution est prête pour la production, le Supply Chain Scientist fournit une documentation qui garantit la maintenabilité de la solution.

Support et maintenance : La solution est opérationnelle et est utilisée par le client pendant que le Supply Chain Scientist surveille l’exécution quotidienne fluide du pipeline de données. Des appels sont régulièrement organisés entre le client et le Supply Chain Scientist pour vérifier que l’optimisation offre le degré de performance de la supply chain attendu. De plus, les supply chains ne sont pas statiques, ainsi, les changements commerciaux ou informatiques, petits ou grands, doivent être examinés : un nouvel entrepôt, un changement de marché, un nouveau processus, etc. Le Supply Chain Scientist propose des modifications adaptées pour accommoder ces différents changements. Des appels de contrôle sont planifiés avec une fréquence convenue, généralement mensuelle.

Foire aux questions (FAQ)

1. Gestion des versions

1.1 Comment fonctionnent les versions chez Lokad ?

Lokad gère toutes les versions en interne, ce qui garantit une transparence totale pour les clients. Toutes les versions susceptibles d’avoir un impact sur un client sont coordonnées avec eux - via les équipes techniques du client - bien à l’avance. En règle générale, Lokad adopte une approche prudente en matière de versions : si une version planifiée ne permet pas un temps de préparation suffisant pour un client, la version est temporairement reportée.

Les versions de Lokad sont très granulaires et la conception permet généralement au client de choisir de ne pas utiliser un élément technique particulier d’une version globale. Ainsi, si nous devons reporter la mise en œuvre d’un élément - pour lequel notre client n’est pas encore prêt - la version globale peut quand même avoir lieu (et mettre en œuvre les autres éléments qui n’ont pas d’impact).

1.2 À quelle fréquence les versions sont-elles publiées ?

Lokad publie une nouvelle version chaque mardi, généralement vers 11 heures (CET).

1.3 Fournissez-vous un plan des prochaines versions ?

Oui, voir Gestion des versions 1.2.

1.4 Un changement de version nécessite-t-il une réinstallation ou simplement un correctif ?

Lokad redéploie, par le biais de moyens automatisés (scripts), sa propre solution. Nous ne corrigeons pas les systèmes en production. Si nous devons déployer un “correctif de sécurité”, nous redéployons la solution par le biais de nos moyens automatisés habituels.

1.5 Combien de temps faut-il pour appliquer une version majeure ?

Le processus automatisé prend environ 1 heure. Il y a un déploiement progressif (machine par machine), car nous avons l’intention de maintenir la plateforme de Lokad opérationnelle et accessible pendant la version. L’opérationnalité pendant un déploiement est discutée dans Gestion des versions 1.7.

1.6 Qui est responsable de l’exécution correcte de la version ?

L’équipe de Lokad prend en charge l’exécution correcte de la version.

1.7 Y a-t-il une interruption de service pendant la version ?

La plupart du temps, non, mais gardez à l’esprit que la solution de Lokad est un système distribué dédié aux calculs à grande échelle. En tant que tel, l’impact d’une version diffère entre les systèmes frontaux et arrière. Les sous-systèmes orientés client, tels que les tableaux de bord, sont conçus pour une disponibilité continue. Les systèmes arrière, tels que ceux chargés de l’exécution des travaux par lots, peuvent être mis en pause pendant quelques minutes (du moins pour certains travaux). Cependant, ces travaux par lots peuvent être planifiés, de sorte que la planification proactive devrait permettre de terminer les travaux par lots en dehors de la période de version.

1.8 Quel est votre processus ou stratégie de test pour une version ?

Lokad utilise des processus automatisés dédiés aux tests et à la vérification de la validité d’une prochaine version. Ces processus comprennent de vastes suites de tests automatisés (mesurées en milliers) ; tests unitaires, tests fonctionnels, tests de performance, etc. Nous avons également développé des outils spécifiques qui nous permettent de reproduire des séquences entières d’exécutions de travaux passés au sein de la plateforme Lokad. Ces outils nous permettent de vérifier que les scripts Envision ont exactement le même comportement avant/après une prochaine version. De plus, nous pouvons vérifier que les profils de performance des scripts existants restent conformes aux attentes du calendrier, telles que définies par nos clients.

1.9 Avez-vous plusieurs environnements ?

Oui, cependant, les environnements alternatifs (au niveau de la plateforme, en dehors de la production) ne sont généralement pas destinés à nos clients. En plus de l’environnement de production et des environnements de développement transitoires, nous avons un environnement “evergreen” qui correspond à la dernière version stable de notre code source. Cela valide un sous-ensemble spécifique de nos processus de test automatisés. Nos clients peuvent accéder à notre environnement “evergreen” afin de vérifier qu’une prochaine version spécifique se comporte comme prévu. Cette situation peut se produire s’il y a une intégration informatique entre Lokad et le client. En pratique, cette situation est rare.

Si l’objectif est de pouvoir exécuter (côte à côte) plusieurs variantes de scripts Envision, alors un compte Lokad peut être partitionné en plusieurs “environnements”. Si l’objectif est de pouvoir effectuer n’importe quel type de test, alors un deuxième compte Lokad peut être fourni à des fins de test transitoire. Cette deuxième approche permet de maintenir le compte client principal (utilisé pour la production) isolé de ces tests.

1.10 Combien de versions différentes peuvent coexister ?

Lokad est un SaaS multi-locataire qui exécute la même version unique pour tous ses clients, cependant, Lokad a la capacité de fonctionner avec autant de versions distinctes que souhaité par le client.

1.11 Un client peut-il refuser une version ?

Comme Lokad est un SaaS multi-locataire qui exécute la même version unique pour tous les clients, il n’est pas possible de refuser une version. Cependant, d’un point de vue commercial, cela est sans objet car toute “modification” est mise en œuvre par l’exécution de scripts Envision au sein de la solution Lokad.

Pour les situations dans lesquelles une version peut être temporairement reportée, voir Gestion des versions 1.1.

1.12 Avez-vous des notes de version ? Les fournissez-vous à vos clients ?

Oui. Ces notes sont partagées en interne (avec nos équipes de scientifiques de la supply chain). Si cela est explicitement convenu dans le cadre d’un contrat, ces notes de version peuvent être rendues accessibles à un client. En pratique, les notes de version de la plateforme Lokad n’intéressent que les personnes qui travaillent avec le code Envision.

1.13 Quel est le processus pour qu’un client demande une évolution de la solution ?

La plupart de nos clients bénéficient d’une offre “logiciel + expert”, où une équipe de scientifiques de la supply chain de Lokad est responsable de la mise en œuvre et de la maintenance de la solution de supply chain d’un client. Ces situations sont connues sous le nom de “supply chain as a service”. Dans ces arrangements, le client interagit régulièrement avec un (ou plusieurs) scientifiques de la supply chain. De plus, la plupart des clients bénéficient d’un comité de pilotage hebdomadaire ou mensuel pour discuter de l’état actuel de la solution et des évolutions souhaitées. Lokad utilise cette méthode pour recueillir toutes les demandes d’évolution et proposer une feuille de route pour la mise en œuvre des changements.

1.14 Est-il possible d’administrer le service web de l’application et de configurer ses paramètres ?

Oui, dans le sens où la plateforme Lokad est programmable par nature. La logique “analytique” de Lokad prend la forme de scripts Envision - Envision étant le DSL (Domain-Specific Language) développé par Lokad dans le but de l’optimisation prédictive de la supply chain.

Ainsi, dans un sens, chaque configuration de paramètre est disponible en utilisant des scripts Envision dans le compte.

2. Performance

2.1 Votre SLA (accord de niveau de service) couvre-t-il un temps de disponibilité de 99.xy% ?

Oui. Le SLA fait partie de notre accord contractuel par défaut. Cependant, la notion de temps de disponibilité dans le contexte d’un système informatique distribué - dédié à l’optimisation prédictive des supply chains - est complexe. Considérez les scénarios suivants : - Lokad reçoit les données client (une étape quotidienne) avec un retard de 2 heures. Cela peut perturber l’efficacité habituelle de nos heuristiques d’allocation des ressources. Cela peut également prolonger le temps nécessaire pour effectuer les tâches en lot de Lokad (par exemple, 75 minutes au lieu des 60 habituelles). Certains peuvent considérer cela comme une indisponibilité de 15 minutes, mais cela est hors de notre contrôle.

• Lokad reçoit les mêmes données client à temps, mais les données présentent une baisse importante des niveaux de stock. Cela déclencherait une interruption des tâches en lot (côté Lokad) et alerterait un scientifique de la supply chain pour enquêter sur le problème. Le scientifique de la supply chain constate qu’une commande de réapprovisionnement automatisée est exceptionnellement importante. Le scientifique de la supply chain décide qu’une évaluation directe de la part du client est nécessaire. Le lendemain, le client confirme que les données de stock étaient corrompues et auraient entraîné une importante dépréciation des stocks. Certains peuvent considérer cela comme une indisponibilité de 24 heures, mais cela semble pratiquement obtus dans ce contexte.

Le plus grand danger pour une solution d’optimisation de la supply chain n’est pas d’être un peu en retard ; c’est d’être très incorrect. Une fois qu’une décision de la supply chain est prise, comme déclencher (incorrectement) une production en lot, l’annuler peut être extrêmement coûteux. Nous encourageons nos clients à ne pas s’attacher arbitrairement à des indicateurs isolés, car cette attitude peut inciter les gens à fournir un travail global inférieur tant qu’il semble satisfaire un KPI (comme un temps de disponibilité de x.y %).

2.2 Garantissez-vous un temps de réponse pour les demandes des utilisateurs inférieur à X secondes ?

Oui, en dessous de 500 ms, mais avec des réserves.

Nous avons conçu ce qui équivaut approximativement à des “tableaux de bord à temps constant”. Sous le capot, l’affichage d’un tableau de bord nécessite une seule demande sur le réseau, et dans notre back-end, nous regroupons toutes les données du tableau de bord pour réduire le nombre de demandes sur le réseau (généralement mesuré en chiffres simples). Ce choix de conception contribue grandement à “garantir” la faible latence de la demande utilisateur typique dans l’affichage d’un tableau de bord. Ce choix de conception empêche également le tableau de bord de devenir encombré de tuiles - chacune nécessitant des demandes sur le réseau - et de ralentir l’expérience utilisateur globale.

En ce qui concerne la durée des tâches en lot, grâce à Envision, nous pouvons fournir des garanties - au moment de la compilation - qu’une tâche en lot sera terminée. Nous pouvons également garantir des temps de terminaison largement reproductibles pour nos tâches en lot. Ces garanties sont obtenues grâce à une analyse statique et à une conception minutieuse du langage Envision - qui rend possible certaines classes d’analyses statiques en premier lieu. Cette approche a des limites, mais elle est largement supérieure aux conceptions qui n’offrent aucune garantie du tout.

Cependant, la latence de bout en bout n’est pas entièrement entre nos mains. Par exemple, nous ne contrôlons pas la qualité de la connexion Internet utilisée par nos clients. Un grand tableau de Lokad prendra du temps à télécharger sur un réseau à faible bande passante.

2.3 Avez-vous des journaux d’audit de performance système ?

Oui. Nous collectons des journaux de performance très granulaires pour toutes les ressources informatiques impliquées : CPU, mémoire, stockage, bande passante, etc. Ces journaux de performance sont utilisés, entre autres, pour s’assurer qu’une nouvelle version de la plateforme, encore non publiée, répond à nos attentes en termes de performance. Nous testons cela en comparant les performances de la nouvelle version avec celles des versions précédentes, telles qu’elles ressortent de ces journaux.

2.4 Est-il possible de surveiller les réponses lentes ou la congestion ?

Oui. La plateforme Lokad est dotée d’un planificateur interne qui peut suivre l’exécution en temps voulu des tâches en lot. La conception de Lokad garantit en grande partie une réponse en temps constant pour toutes les demandes - à l’exception des opérations à longue durée d’exécution, qui sont traitées comme des tâches en lot.

Comme Lokad est une plateforme multi-locataire, une grande partie de la surveillance des performances n’est pas directement accessible à nos clients (car elle concerne les performances de la plateforme dans son ensemble). Comme on peut s’y attendre, les équipes de Lokad surveillent en permanence les performances de notre plateforme.

2.5 Avez-vous des équilibreurs de charge ?

Oui. Les équilibreurs de charge de Lokad sont principalement destinés à assurer la fiabilité plutôt qu’à améliorer les performances. L’équilibrage de charge au niveau du réseau est effectué par la couche de mise en réseau de la plateforme de cloud computing que nous utilisons (Microsoft Azure). Cependant, la répartition de la charge de traitement des données internes, gérée par la plateforme Lokad, n’est pas gérée par des équilibreurs de charge, mais par un orchestrateur interne associé à notre pile de compilation.

2.6 Regroupez-vous des ressources telles que des connexions de base de données, des sessions, etc. ?

Oui. Cependant, la plateforme Lokad ne repose pas sur une base de données transactionnelle pour fonctionner. Il n’y a donc pas de connexions de base de données à regrouper. Néanmoins, nous regroupons de nombreuses autres ressources, chaque fois que cela a du sens d’un point de vue des performances.

2.7 Prenez-vous en charge le traitement parallèle ?

Oui. Envision (notre DSL) est conçu autour de la notion d’exécution parallélisée automatique. La plateforme Lokad exploite activement la parallélisation à plusieurs niveaux : au niveau du cœur du processeur grâce aux opérations SIMD (Single Instruction/Multiple Data) ; au niveau du processeur grâce aux exécutions multi-threadées ; et au niveau du cluster grâce au calcul distribué. Comme le traitement parallèle est un aspect fondamental de la conception d’Envision, la quasi-totalité des charges de travail exécutées sur la plateforme Lokad bénéficient d’une parallélisation étendue, par défaut, sans aucun effort spécifique de la part de nos clients ou de nos scientifiques de la supply chain.

2.8 Prenez-vous en charge la mise en cache des données fréquemment consultées ?

Oui. Cependant, la mise en cache est souvent utilisée comme solution de contournement pour faire face aux limitations de performances des bases de données transactionnelles. Étant donné que la plateforme Lokad n’inclut pas de bases de données transactionnelles, nous n’utilisons pas la mise en cache à cette fin.

2.9 Compressez-vous les données pour réduire le trafic réseau ?

Oui, nous compressons la plupart du trafic réseau. Cependant, nous ne pouvons pas tout compresser car cela présenterait une vulnérabilité de sécurité connue sous le nom de BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext). BREACH se produit lorsque trois facteurs sont réunis.

1. Une réponse est compressée.

2. Une réponse contient un secret.

3. Une réponse contient une chaîne de caractères qui peut être collectée par l’attaquant qui crée la requête.

Afin de se protéger contre BREACH, Lokad désactive la compression sur toutes les réponses pour lesquelles la troisième condition est vraie. Nous compressons également les données pour des raisons autres que la réduction du trafic réseau ; premièrement, pour réduire les coûts de stockage des données ; et deuxièmement, pour réduire les retards de calcul.

2.10 Effectuez-vous des tests de performance ?

Oui. Lokad dispose d’une couche d’instrumentation automatisée orientée performances. Cette série d’outils nous permet d’évaluer, avant chaque version, la différence de performances de la prochaine version par rapport à celle obtenue avec la version actuellement déployée. Cet outil nous permet de reproduire les mêmes charges de travail, telles qu’observées en production, et de surveiller les performances résultantes ; non seulement en termes de temps écoulé, mais en tenant compte de toutes les ressources informatiques pertinentes (mémoire, bande passante, E/S, CPU, etc.).

2.11 Surveillez-vous les performances au niveau de la transaction ?

Oui. Cependant, comme la plateforme Lokad n’utilise pas de base de données transactionnelle, il n’y a pas de “transactions” à surveiller (au sens traditionnel). L’équivalent le plus proche est l’exécution des scripts Envision. Pour ces scripts, nous surveillons les performances à un niveau très granulaire, ce qui est approximativement analogue à la surveillance des détails de l’exécution du plan de requête (du point de vue d’une base de données transactionnelle).

Consultez notre documentation sur la Sécurité pour plus d’informations sur les “transactions” dans la solution Lokad : Autorisation 3.6 et Journalisation et surveillance 5.3.

2.12 Quel est l’impact des utilisateurs concurrents sur la solution ?

Presque aucun. La conception de Lokad garantit que les tableaux de bord peuvent être servis en temps constant même pour un grand nombre d’utilisateurs (selon les normes B2B). Cette approche contraste fortement avec de nombreuses architectures alternatives, notamment les bases de données transactionnelles et les cubes d’intelligence d’affaires.

Cependant, étant donné que chaque utilisateur individuel pourrait (s’il dispose des droits système appropriés) déclencher des charges de travail arbitrairement importantes, le nombre d’utilisateurs concurrents est, au mieux, une préoccupation secondaire en ce qui concerne les performances de la solution. En ce qui concerne l’optimisation prédictive de la supply chain, les travaux par lots utilisés pour effectuer les analyses d’intérêt représentent plus de 99% de la charge de travail. Les moins de 1% restants sont consacrés à la satisfaction des demandes des utilisateurs.

2.13 Le système est-il conçu pour être mis à l’échelle verticalement et horizontalement ?

Oui. De notre point de vue, la mise à l’échelle verticale et horizontale sont complémentaires, et la conception de la plateforme Lokad les exploite toutes les deux. L’orchestrateur interne - celui en charge de la parallélisation - commence généralement par la mise à l’échelle verticale, car celle-ci facilite largement la colocalisation des données. Ensuite, l’orchestrateur exploite la mise à l’échelle horizontale si la charge de travail est suffisamment importante pour bénéficier d’une exécution sur plusieurs machines.

2.14 Effectuez-vous une mise à l’échelle automatique des calculs et du stockage selon les besoins ?

Oui. La plateforme Lokad est multi-locataire. Grâce à la multi-locataire, nous effectuons des allocations de ressources de calcul à grande échelle et à faible latence. Cela signifie que la mise à l’échelle automatique des calculs fournie par Lokad est des ordres de grandeur plus rapide que la création de grandes machines virtuelles (VM) par un fournisseur de cloud computing. La mise à l’échelle automatique du stockage est largement réalisée en exploitant les propriétés de mise à l’échelle automatique du magasin de clés persistant, telles que fournies par la plateforme de cloud computing sous-jacente (Microsoft Azure).

2.15 Comment votre application gère-t-elle les besoins en “Big Data” ?

La plateforme Lokad a été spécifiquement conçue pour le traitement des “Big Data”. En janvier 2023, l’ensemble de la plateforme Lokad gère environ 1 pétaoctet de données pour l’ensemble de notre base de clients. Notre plateforme peut traiter des fichiers individuels allant jusqu’à 100 Go, et nous traitons régulièrement des tables avec des dizaines de milliards de lignes. Accédez à la sécurité de Lokad 4.10

Ce point est particulièrement technique et dépasse le cadre de ce document. Pour une explication détaillée, nous vous recommandons la série en 4 parties de Victor Nicollet sur la conception de la machine virtuelle Envision.

2.16 La solution basée sur le cloud de Lokad peut-elle être configurée en fonction de contraintes de bande passante et de latence (côté client) ? Par exemple : bande passante = 3 Mbps (téléchargement) / 1 Mbps (envoi), latence = 600-800 ms

Oui, l’application web conçue par Lokad a été développée pour pouvoir prendre en charge des scénarios où la connectivité est “faible” (tant en termes de bande passante que de latence). Ces préoccupations sont principalement traitées par des choix fondamentaux de conception technologique. Ces choix de conception architecturale distinguent également Lokad de la norme. Les préoccupations liées à la bande passante sont traitées de deux manières. Tout d’abord, nous sommes économes en ce qui concerne les composants tiers JavaScript. Nous avons moins de 1 Mo d’actifs à récupérer initialement. Deuxièmement, la plateforme offre un contrôle complet sur la quantité de données à inclure dans chaque tableau de bord. Ainsi, si la connectivité est faible, il est possible de rendre le tableau de bord approprié “léger”. En ce qui concerne les préoccupations de latence, nos tableaux de bord ont été conçus pour regrouper toutes les données pertinentes dans une seule requête HTTP. Cela réduit les frictions subies par les utilisateurs finaux à faible latence.

2.17 Quelles sont les capacités moyennes et maximales de débit de données de la solution par rapport à une référence de 1 (bas de gamme) et 5 (haut de gamme) messages par seconde ?

La plateforme Lokad n’opère pas avec des messages. De même, les interactions avec la plateforme Lokad ne sont pas effectuées via des messages. Cependant, le débit est important pour traiter rapidement de vastes ensembles de données transactionnelles. La plateforme Lokad gère, au total, plus de 1 pétaoctet de données. Nous traitons régulièrement plus de 1 téraoctet par minute pour de grands lots de calcul.

Un débit très élevé est important pour éviter les retards opérationnels lors du traitement de très grands ensembles de données (des dizaines de téraoctets) avec des calculs complexes comprenant des étapes d’apprentissage automatique et d’optimisation mathématique.

2.18 Quelle taille de messages la solution peut-elle gérer ? Veuillez fournir des détails sur les valeurs minimales, maximales et moyennes.

La plateforme Lokad n’opère pas avec des messages. La chose la plus proche serait les “fichiers plats”. Ces fichiers plats peuvent être envoyés à Lokad et récupérés depuis Lokad. La plateforme Lokad peut traiter des fichiers individuels d’une taille maximale de 100 Go. Cependant, il ne s’agit pas d’une pratique recommandée car cela peut être un peu compliqué (non pas pour Lokad, mais pour les clients qui devront se familiariser avec des outils externes pour produire et consommer les gros fichiers).

3. Incidents

3.1 Quel est le processus pour qu’un client signale un incident ?

La plupart de nos clients bénéficient d’un forfait qui inclut l’accès à notre équipe de scientifiques de la supply chain. Ces scientifiques de la supply chain sont le premier point de contact pour signaler les incidents. En cas d’incident, nous suggérons aux clients de téléphoner directement à leur scientifique de la supply chain - si le problème est urgent - ou d’envoyer un e-mail. Les scientifiques de la supply chain s’occupent de la gestion des incidents, y compris des éventuelles escalades au sein de l’organisation de Lokad.

3.2 Proposez-vous un système de ticket ?

Oui. Lokad utilise un système de ticket tiers. Cependant, à partir de janvier 2023, nous avons commencé à développer une solution interne qui offre une intégration étroite avec le reste de notre plateforme.

3.3 Prenez-vous en charge le signalement des incidents vers des outils tiers ?

Oui, dans le cadre d’un accord contractuel dédié.

Dans le contexte de l’optimisation prédictive de la supply chain, les “incidents” peuvent varier et être difficiles à définir. En général, nos clients ne considèrent pas les événements mineurs au niveau de la plateforme (comme les temps d’arrêt de quelques minutes) comme des “incidents”. Ce sont plutôt des anomalies réelles de la supply chain - qui peuvent ou non refléter des problèmes avec les scripts Envision mis en œuvre dans le compte client - qui seraient de meilleurs candidats. Les services informatiques externes sont rarement impliqués dans la résolution de ces incidents.

3.4 Comment garantissez-vous une disponibilité élevée ?

Lokad est devenu un précurseur (vers 2010) des plateformes de cloud computing précisément pour garantir une disponibilité plus élevée. En plus de rendre l’infrastructure redondante (voir Incidents 3.5), la conception de la solution de Lokad met fortement l’accent sur la simplicité. Contrairement aux solutions logicielles d’entreprise comparables, nous avons beaucoup moins de dépendances complexes (presque d’un ordre de grandeur). Une énorme couche de complexité absente de notre solution est une base de données transactionnelle. En ayant moins de pièces mobiles, nous avons beaucoup moins de modes de défaillance, ce qui nous aide à maintenir une disponibilité élevée pour nos clients (qui sont répartis sur plusieurs fuseaux horaires).

3.5 Disposez-vous d’une infrastructure redondante (si oui, comment) ? Évitez-vous les points de défaillance uniques ?

Oui. Nos systèmes critiques sont redondants, précisément pour éviter les points de défaillance uniques. Les systèmes redondants incluent les sous-systèmes qui prennent en charge les protocoles étatiques tels que SFTP. De plus, le stockage des données est non seulement redondant, mais également géographiquement redondant. Cette redondance est utilisée lors de nos mises à jour pour préserver le temps de disponibilité pendant le déploiement.

3.6 Comment récupérez-vous des pannes matérielles ?

La récupération de la plupart des pannes matérielles est effectuée de manière transparente par la plateforme de cloud computing utilisée par Lokad. La redondance intégrée à la plateforme de Lokad garantit que les pannes matérielles transitoires n’affectent pas le temps de disponibilité pendant que la plateforme de cloud computing réalloue une nouvelle ressource non défectueuse. Pour le stockage des données persistantes, Lokad utilise uniquement des services (par exemple, des stores clé-valeur) qui sont eux-mêmes protégés contre les pannes matérielles grâce à leurs propres couches de redondance.

3.7 Avez-vous une sauvegarde ?

Oui. Nous disposons d’un environnement de sauvegarde dédié aux scénarios de récupération après sinistre graves (au-delà d’une interruption au niveau du centre de données). Cet environnement de sauvegarde est complètement isolé de l’environnement de production. L’environnement de sauvegarde peut lire à partir de l’environnement de production (mais ne peut pas écrire), tandis que l’environnement de production ne peut ni lire ni écrire à partir de l’environnement de sauvegarde.

3.8 Avez-vous un plan de reprise après sinistre ?

Oui. Au niveau technique, le plan de reprise après sinistre couvre la ré-instantiation complète de la plateforme Lokad. Cette partie utilise largement les processus automatisés que nous avons mis en place pour nos versions hebdomadaires. Au niveau commercial, le plan de reprise après sinistre comprend le contact avec tous nos clients, généralement en suivant un processus convenu avec chacun d’entre eux. Pour la plupart de nos clients, les scientifiques de la supply chain désignés agissent en tant que points de contact principaux pendant la durée de la reprise.

3.9 La solution prend-elle en charge la récupération à un instant donné (PITR) à travers la base de données et les données en dehors de la base de données ? Quel est l’objectif de point de récupération (RPO) de la solution ?

La solution de Lokad dispose d’une conception de protection continue des données grâce à la sauvegarde incrémentielle en direct de son magasin d’événements et de sa source de contenu. Par conséquent, nous pouvons effectuer une récupération à un instant donné (jusqu’au niveau de la minute).

Nous avons un RPO d’une minute pour les sinistres au niveau du centre de données - si les données ne sont pas compromises. Nous y parvenons en exploitant des écritures géographiquement redondantes de notre magasin clé-valeur persistant. Si le magasin clé-valeur est compromis, Lokad récupère à partir de son stockage de sauvegarde (maintenu aussi isolé que possible de nos systèmes de production), également hébergé dans un lieu géographique différent. Dans ce cas, nous avons un RPO de 12 heures.

3.10 La solution est-elle capable de générer des alertes en cas de violation d’intégrité ? La solution a-t-elle la capacité d’ajouter ou d’étendre des vérifications d’intégrité selon les besoins ?

Oui, bien que ce type de problème reflète principalement une conception logicielle basée sur une base de données transactionnelle. La plateforme de Lokad n’opère pas avec une base de données transactionnelle mais avec un magasin d’événements, adoptant une conception basée sur l’événement plutôt qu’une conception relationnelle. Cela n’élimine pas la nécessité de faire respecter l’intégrité des données, mais ces préoccupations sont abordées de manière alternative.

En ce qui concerne le traitement des données client, Envision (le DSL de Lokad) dispose de capacités étendues pour vérifier sa qualité. Grâce à Envision, il est possible de vérifier l’intégrité et de générer des alertes. Cette logique peut être étendue ou modifiée de la manière jugée appropriée par le client.

3.11 Les sauvegardes sont-elles testées périodiquement pour vérifier leur fonctionnalité de restauration des données ?

Oui. La conception basée sur l’événement de Lokad, combinée à son magasin adressable par contenu, facilite beaucoup plus les tests de sauvegarde et de restauration des données que pour la plupart des conceptions courantes qui utilisent des bases de données relationnelles (comme SQL).

Voir aussi Incidents 3.7.

3.12 Les plans de reprise après sinistre sont-ils testés périodiquement pour vérifier leur fonctionnalité de reprise après sinistre ?

Oui. La stratégie de déploiement de Lokad utilise des scripts automatisés de bout en bout, en limitant délibérément les interventions humaines - une exception notable étant la possibilité de déclencher un redéploiement complet de la production. Cette approche fortement automatisée facilite les tests de fonctionnalité de reprise après sinistre.

Voir Incidents 3.8.

3.13 La récupération peut-elle être effectuée pour des clients individuels et/ou des environnements clients ?

Oui. Nos outils internes prennent en charge la possibilité de restaurer le compte d’un client sélectionné (y compris la restauration du compte/environnement à un moment donné). Cependant, étant donné que la plateforme Lokad elle-même dispose de capacités de versioning étendues (par exemple, les scripts Envision sont versionnés et les versions précédentes sont accessibles depuis l’application), cette fonctionnalité est rarement utilisée.

3.14 Les plans de sauvegarde et de reprise après sinistre répondent-ils aux objectifs de temps de récupération (RTO - Recovery Time Objective), de point de récupération (RPO - Recovery Point Objective) et aux exigences de scénarios de sinistre (tels que définis et convenus avec les clients respectifs) ?

Oui. L’objectif de temps de récupération (RTO) fait référence ici à la durée pendant laquelle la plateforme Lokad pourrait théoriquement être hors service sans causer de dommages importants au client, ainsi qu’au temps nécessaire pour restaurer la plateforme et ses données afin qu’elle puisse reprendre ses opérations normales après un incident majeur.

Le RTO dépend beaucoup des détails spécifiques des processus pris en charge/fournis par Lokad. Par exemple, un client qui compte sur Lokad pour planifier des commandes d’achat mensuelles à l’étranger peut avoir un RTO d’une semaine. À l’inverse, un client qui compte sur Lokad pour optimiser l’expédition quotidienne de son inventaire depuis un entrepôt vers plusieurs magasins peut avoir un RTO d’une heure.

En pratique, diverses mesures techniques peuvent être mises en place pour améliorer considérablement le RTO (c’est-à-dire réduire le temps d’arrêt théorique). Par exemple, des “décisions de basculement” peuvent être calculées à l’avance. Ces décisions peuvent être utilisées si la plateforme Lokad n’est pas disponible. Comparées aux décisions optimisées “normales”, les décisions de basculement peuvent présenter une performance d’approvisionnement légèrement dégradée étant donné qu’elles ne tireraient pas parti des données les plus récentes.

Pour nos comptes gérés, il incombe au Supply Chain Scientist de Lokad de concevoir conjointement avec les équipes opérationnelles du client un processus qui offre un RTO élevé, tout en garantissant un impact commercial minimal en cas d’incident réel. De notre point de vue, ce défi est avant tout un problème de supply chain plutôt qu’un problème informatique.

Voir aussi Incidents 3.9.

3.15 Si un défaut n’est pas reproductible dans l’environnement de test, Lokad peut-il vérifier que le défaut s’est produit à partir des journaux et des données de support, et s’assurer que le défaut est corrigé conformément à l’accord de niveau de service (SLA - Service Level Agreement) ?

Oui, les défauts peuvent être reproduits dans nos environnements. La reproductibilité stricte de tous les états de données et de tous les calculs est un principe de conception fondamental de la plateforme et de l’architecture de Lokad. Par exemple, le système de fichiers au sein de la plateforme Lokad est entièrement versionné (comme Git), précisément pour répondre à cette préoccupation.

Il convient de noter que les journaux sont plus efficaces pour résoudre les problèmes triviaux, tels que les temps d’arrêt du serveur. Lorsqu’il s’agit de résoudre des problèmes complexes et des défauts dans un environnement de données à grande échelle - où des téraoctets de données sont impliqués - les journaux sont souvent insuffisants.

Ainsi, bien que Lokad conserve et consulte des journaux lorsque cela est approprié, nous ne nous appuyons pas sur les journaux pour résoudre les défauts ou vérifier qu’ils ont été corrigés. Au lieu de cela, nous exploitons principalement des choix de conception supérieurs pour fournir une meilleure visibilité, traçabilité et reproductibilité.

Ces choix de conception délibérés nous permettent d’identifier, de reproduire et de corriger les défauts d’une manière qui ne serait pas possible en se basant uniquement sur les journaux.

Veuillez consulter Architecture de Lokad pour une description détaillée des différents choix de conception que nous adoptons pour éviter certaines classes courantes de problèmes logiciels.

3.16 Conservez-vous des enregistrements de toutes les demandes de service et de tous les appels de service (y compris la catégorie de chaque appel) effectués par l’entreprise cliente ? Les enregistrements comprennent-ils : l’identité de la personne appelante et de la personne appelée ; la nature de l’erreur, du problème ou de l’incident signalé ; le temps de réponse de Lokad ; la disposition de l’appel de service ; la résolution ; les temps de résolution ; et la disponibilité du système ?

Oui, la plateforme de Lokad dispose de fonctionnalités de gestion des tâches/tickets/problèmes qui fournissent les détails mentionnés.

En ce qui concerne les “résolutions”, il convient de noter que la philosophie de la supply chain quantitative (QSC) de Lokad consiste à trouver le compromis le plus avantageux sur le plan financier lorsqu’un problème se présente. La QSC n’est pas, techniquement, une approche de “résolution de problèmes”, car les problèmes de supply chain ne sont pas des problèmes qui sont “résolus”, mais plutôt atténués en faisant des compromis financièrement éclairés.

En résumé, Lokad possède les outils et les processus nécessaires pour résoudre rapidement les “problèmes simples” (comme les temps d’arrêt du serveur) de manière directe. Lorsqu’il s’agit de problèmes de supply chain plus importants et plus conséquents (comme l’allocation des stocks de détail ou les problèmes de réapprovisionnement des stocks), il s’agit généralement de discussions plus ouvertes et continues avec les clients sur les compromis qui maximisent leur retour sur investissement.

4. Architecture

4.1 Quels langages de programmation utilisez-vous ?

La plateforme Lokad est développée en C#, F# et TypeScript. La plateforme comprend également Envision (DSL de Lokad), qui est utilisé pour mettre en œuvre les solutions de supply chain spécifiques aux clients.

4.2 Quelle suite de développement utilisez-vous ?

Les équipes d’ingénierie logicielle de Lokad utilisent Microsoft Visual Studio. Les équipes de scientifiques de la supply chain utilisent la plateforme Lokad elle-même, qui dispose de sa propre suite de développement.

4.3 Quel système d’exploitation prenez-vous en charge ?

Lokad est une plateforme basée sur le web et nous prenons en charge tous les systèmes d’exploitation qui ont accès à un navigateur web moderne (par exemple, Firefox). En interne, la plateforme de Lokad est compatible à la fois avec Linux et Microsoft Windows, bien que tous nos systèmes de production soient déployés sous Linux (Ubuntu).

4.4 Quel système de base de données utilisez-vous ou prenez-vous en charge ?

Lokad prend en charge tous les systèmes de base de données capables de produire des exportations de fichiers plats. Cela inclut pratiquement tous les systèmes de base de données du marché, y compris les modèles plus anciens. En interne, Lokad n’utilise pas de système de base de données, mais un magasin clé-valeur. Au moment de la rédaction (janvier 2023), nous utilisons Blob Storage fourni par Microsoft Azure.

4.5 Quel système de mise en cache utilisez-vous ?

Lokad a développé ses propres sous-systèmes de mise en cache en C#/.NET. Ces sous-systèmes sont étroitement intégrés au reste de la solution et ne reflètent pas les systèmes de mise en cache traditionnels destinés principalement à atténuer les problèmes de performance avec une base de données relationnelle (que Lokad n’a pas).

4.6 Comment la solution gère-t-elle les certificats ?

Lokad exploite Let’s Encrypt grâce à des renouvellements de certificats automatisés.

4.7 Quelles sont les prérequis techniques pour utiliser la solution ?

Le principal prérequis technique est un système de transaction qui permet de suivre les stocks. De plus, il est utile que le client ait une certaine expérience de l’extraction de données (sous forme de fichiers plats) à partir de ses systèmes transactionnels, mais cela n’est certainement pas un prérequis.

4.8 Indiquez toutes les licences tierces supplémentaires requises pour utiliser la solution de Lokad (par exemple, OS, SQL,…).

N/A. Lokad ne nécessite aucune licence tierce pour fonctionner. Un large éventail d’outils open-source existe pour prendre en charge l’intégration de Lokad (c’est-à-dire des fichiers plats transférés via FTPS ou SFTP) ; par conséquent, aucune licence tierce n’est requise, même indirectement, pour bénéficier de la plateforme Lokad.

4.9 La solution nécessite-t-elle des plug-ins de navigateur ou un logiciel spécial ?

Lokad est une application web. Elle ne nécessite pas de plug-ins de navigateur ni de logiciel spécial.

4.10 Quelles sont les interfaces d’entrée et de sortie de l’application ?

La solution de Lokad offre une interface web - accessible via HTTPS - et des protocoles de fichiers, à savoir SFTP et FTPS.

4.11 Comment garantissez-vous l’absence de fuites de données entre les locataires ?

La solution de Lokad sépare les données des locataires par sa conception même, ce qui garantit qu’aucune fuite de données (même accidentelle) ne se produit. De plus, tout le code livré en production fait l’objet d’une revue par les pairs, offrant ainsi une couche de protection supplémentaire. Enfin, nous demandons aux chercheurs en sécurité (personnes effectuant des tests d’intrusion) d’enquêter spécifiquement sur la possibilité de fuites de données. Nous leur donnons accès à plusieurs comptes Lokad - dans un environnement dédié et entièrement isolé qui reproduit l’environnement de production - afin qu’ils puissent vérifier de manière agressive cette propriété de notre plateforme.

4.12 La solution peut-elle être conteneurisée ?

Oui, mais il y a peu ou pas d’avantages à conteneuriser la plateforme de Lokad. La conteneurisation apporte de la valeur lorsqu’il existe des dépendances complexes (par exemple, une base de données transactionnelle, un système de mise en cache isolé, etc.). Nous n’utilisons pas de conteneurs en production ou en développement, ce qui améliore notre sécurité en éliminant des classes entières de vulnérabilités. Au lieu de cela, nous maintenons la solution suffisamment simple pour que le déploiement puisse être effectué même avec de petits scripts shell.

4.13 Les composants GUI peuvent-ils être découplés du backend ?

Oui, les composants GUI (dans ce cas, les interfaces web) sont autonomes. Cette conception permet d’obtenir une disponibilité plus élevée. Les utilisateurs finaux peuvent accéder aux tableaux de bord de leur compte Lokad même si une panne soudaine affecte l’un des autres sous-systèmes.

4.14 L’application Lokad prend-elle en charge les fonctions de localisation (telles que le changement de langue) ?

Oui, l’application prend en charge les fonctions de localisation. Toutes les interfaces utilisateur produites par la plateforme de Lokad peuvent être localisées dans n’importe quelle langue. En particulier, toute l’infrastructure technologique adopte l’UTF-8, afin de prendre en charge tous les jeux de caractères qui existent au-delà du latin. En particulier, toute interface utilisateur produite par la plateforme de Lokad peut être relocalisée - après livraison - dans une autre langue.

4.15 Est-il possible pour les utilisateurs finaux de mettre à jour ou de créer de nouvelles traductions après la livraison des données post-traitées par Lokad ?

Oui, voir 4.14 ci-dessus.

4.16 Votre système dispose-t-il d’une aide intégrée ? Si oui, dans quelle(s) langue(s) ?

Oui, Lokad est livré avec une documentation publique très complète (en anglais). Cependant, l’utilisation de la plateforme Lokad implique la création d’interfaces utilisateur sur mesure et notre processus habituel comprend au moins deux formes de documentation ou d’aide.

Tout d’abord, les tableaux de bord créés dans la solution Lokad sont conçus pour être documentés de manière contextuelle - directement à partir du tableau de bord lui-même. En particulier, nous avons même une tuile Markdown dédiée à la documentation en texte enrichi. Deuxièmement, nos livrables comprennent un “Manuel de procédures conjointes”. Dans l’ensemble, le manuel fournit une analyse détaillée non seulement de la mécanique de la solution, mais aussi de la raison pour laquelle chaque élément a été sélectionné (et comment il répond aux besoins spécifiques de la chaîne d’approvisionnement du client).

4.17 L’application web est-elle responsive ?

L’application web de Lokad, ainsi que ses supports (comme la documentation technique), ont été conçus pour être responsive. Cependant, certaines fonctionnalités avancées, comme l’édition de code, sont impraticables sur les appareils mobiles et/ou les tablettes. Ainsi, la conception vise à maximiser la réactivité pour les activités prévues sur les PC et les appareils plus petits, respectivement.

4.18 Si votre système est une application web, quels navigateurs et quelles versions prenez-vous en charge ? Quelle est votre norme minimale de navigateur internet ?

Lokad est une application web et nous prenons en charge les principaux navigateurs web “evergreen” tels que Chrome, Firefox et Safari. Nous n’essayons pas de prendre en charge les anciens navigateurs pour des raisons de sécurité, car le fait de prendre en charge ces navigateurs met implicitement nos clients en danger. En d’autres termes, un navigateur vulnérable peut être exploité par un acteur malveillant pour exfiltrer des données. Cela étant dit, nous sommes également assez conservateurs en ce qui concerne les nouvelles fonctionnalités des navigateurs. En règle générale, nous évitons de prendre en charge les fonctionnalités des navigateurs qui n’ont pas été adoptées par tous les principaux navigateurs web depuis au moins 1 an.

4.19 Pour les applications mobiles et tablettes, quels systèmes d’exploitation (et versions) Lokad prend-il en charge ?

N/A. Comme Lokad est une application web fournie en tant que service (SaaS), nos clients ne sont pas concernés par la prise en charge des systèmes d’exploitation. En interne, Lokad est développé sous Windows, tandis que notre environnement de production hébergé dans le cloud est sous Linux. Ainsi, nous avons une grande confiance dans la portabilité de la solution Lokad. Bien que nous ne ressentions aucun besoin actuel de modifier cette configuration, nous nous adapterons en fonction des preuves valides qui se présenteront.

4.20 L’application web Lokad peut-elle fournir des notifications aux utilisateurs finaux ? Si oui, quelle technologie/protocole est utilisé ?

Oui, Lokad a la capacité d’envoyer des notifications via des notifications de type hook HTTP programmables. Ces hooks peuvent être utilisés pour utiliser un système tiers, souvent déjà en place dans l’entreprise cliente, pour envoyer une notification par e-mail ou tout autre type de notification jugé approprié. Les hooks sont également généralement utilisés pour signaler la disponibilité des données à récupérer à partir de la plateforme Lokad via SFTP ou FTPS.

4.21 Y a-t-il des éléments partagés sur la solution qui sont communs à tous les clients (comme les fonctions de surveillance, les solutions de sauvegarde ou de gestion des correctifs, etc.) ?

Oui, Lokad étant une application multi-tenant, les capacités au niveau de l’infrastructure sont toutes partagées entre/parmi les locataires, c’est-à-dire les comptes clients. Cela inclut la surveillance du temps de disponibilité, des performances et, pour des raisons de sécurité, la sauvegarde, la gestion des correctifs, la mise à niveau, etc.

4.22 La solution permet-elle une fonctionnalité de messagerie à destination multiple (c’est-à-dire la possibilité d’envoyer un message à plusieurs destinataires ou applications) ?

La plateforme Lokad n’opère pas avec des messages. Cependant, nous fournissons des capacités de hook HTTP qui peuvent être utilisées pour générer des notifications de message arbitrairement complexes, généralement via des systèmes tiers à faible coût. Ces notifications sont parfois utilisées par les équipes de la chaîne d’approvisionnement pour surveiller l’achèvement en temps voulu des lots de calculs critiques avec la plateforme Lokad.

4.23 Tous les systèmes et composants critiques utilisent-ils la même source de temps (NTP) ou synchronisent-ils leurs horloges de manière fiable ?

Oui. Lokad utilise le service NTP par défaut fourni avec Ubuntu - ntp.ubuntu.com. Plus précisément, ntpd est exécuté en tant que service de synchronisation du temps, qui se synchronise avec une source de temps NTP externe accessible via le réseau.

4.24 Existe-t-il une liste d’inventaire des actifs ou une base de données de gestion de configuration (CMDB) ?

Oui, nous avons un logiciel de gestion des actifs informatiques pour soutenir nos processus. Cette plateforme nous aide à maintenir une liste d’inventaire complète des actifs et sert de base de données de gestion de configuration (CMDB). Grâce à ce système, nous pouvons suivre, gérer et allouer efficacement les actifs matériels et logiciels dans toute l’organisation. Nos équipes ont la capacité d’identifier rapidement l’état, l’emplacement et la configuration de chaque actif, ce qui garantit des réponses rapides aux changements, aux mises à jour ou aux problèmes potentiels.

De plus, notre outil offre des fonctionnalités qui permettent une gestion détaillée du cycle de vie, garantissant que les actifs sont catalogués avec précision depuis l’approvisionnement jusqu’à la fin de vie. Les capacités d’audit automatisées, associées à des fonctionnalités de reporting détaillées, garantissent que nous maintenons une visibilité et un contrôle complets sur notre environnement informatique, facilitant la conformité et l’allocation efficace des ressources.

4.25 Chaque connexion à un réseau externe est-elle terminée par un pare-feu (par exemple, Internet, réseaux partenaires) ?

Non, nous ne terminons pas chaque connexion à un réseau externe par un pare-feu, que ce soit Internet ou des réseaux partenaires. Notre décision est basée sur des préoccupations réelles concernant l’efficacité et les implications de telles mesures dans le monde réel.

De notre point de vue, bien que les pare-feu soient généralement considérés comme une première ligne de défense, ils peuvent ironiquement étendre la surface d’attaque. Plus nous intégrons de composants et de systèmes, plus nous introduisons de points faibles potentiels. Les pare-feu, en raison de leur nature, fonctionnent en tant que processus à privilèges élevés. Cela signifie qu’ils deviennent des cibles principales pour les cyberattaques, et lorsque ils sont compromis, les résultats peuvent être dévastateurs. Un cas illustratif est l’attaque SolarWinds, où les systèmes même destinés à protéger les informations ont été exploités, entraînant des violations importantes.

De plus, la présence de pare-feu stricts peut être contre-productive sur le plan pratique. Notre expérience a montré que de tels systèmes incitent souvent les employés à chercher des moyens alternatifs pour accéder et partager des informations. Cela implique généralement de contourner complètement le réseau de l’entreprise (empêchant ainsi toute surveillance), en utilisant des connexions personnelles 4G ou 5G à partir de leurs propres appareils. De telles pratiques augmentent involontairement le risque de violations de sécurité et de fuites de données.

Ainsi, bien que nous soyons profondément engagés en matière de sécurité, notre approche est holistique et basée sur des considérations pratiques plutôt que de s’appuyer uniquement sur des mesures traditionnelles.

4.26 Le réseau dispose-t-il d’un environnement DMZ qui transmet, traite ou stocke des systèmes critiques (comme les serveurs Web, DNS, les services de répertoire et l’accès à distance), ainsi que des données clients ?

Non, Lokad n’utilise pas d’environnement DMZ traditionnel au sein de notre réseau pour transmettre, traiter ou stocker des systèmes critiques et des données clients. Nous avons plutôt adopté une approche de confiance zéro en matière de sécurité réseau.

Ce modèle ne repose pas sur des DMZ, mais fonctionne plutôt sur le principe de “ne jamais faire confiance, toujours vérifier”. Chaque demande d’accès est validée et authentifiée, indépendamment de son origine, qu’elle provienne de l’intérieur ou de l’extérieur de l’organisation.

Cela garantit une posture de sécurité plus robuste et holistique, car cela ne dépend pas de défenses périmétriques comme une DMZ, mais se concentre plutôt sur la sécurisation de chaque point d’accès individuel et de chaque transaction de données. Nous pensons que l’approche de confiance zéro offre une protection supérieure pour nos systèmes critiques et les données de nos clients.