Schweltai, startup valaisanne de logiciel sur mesure et d’IA appliquée, fondée par Marcos Fernandez

Du problème métier à l’IA en production.

Logiciel sur mesure, intégrations et automatisation pour les entreprises en Suisse. L’IA là où elle apporte quelque chose, des règles là où elles suffisent, une personne là où il faut décider.

Fondée par un développeur passé par Capgemini, Indra Group et Ricoh Europe.

Une demande client, lue par le moteur de la démo

Message reçu

Bonjour,
Je m’appelle Laura Rey. Nous quittons notre appartement de 3.5 pièces (85 m²) à Sion et nous avons besoin d’un nettoyage de fin de bail avec les vitres, le 14 novembre.
Vous pouvez me joindre au 079 000 12 34 ou à laura.rey@example.ch.
Merci !

Données extraites

Client
Laura Rey
Prestation
Fin de bail + vitres
Taille
85 m²
Lieu
Sion
Date
14 novembre
Contact
+41 79 000 12 34
Devis
CHF 790
  1. Reçu
  2. Lu
  3. Contrôlé
  4. Chiffré
  5. À valider
Devis de CHF 790 prêt, en attente d’une validation humaine. Moteur de règles réel, exécuté dans votre navigateur. Rien n’est envoyé.

Une demande, quatre outils, trois ressaisies.

C’est souvent ainsi que le travail circule dans une PME. Faites défiler : le même processus, d’abord tel qu’il est, puis transformé en un système.

Le même processus, avant et après Avant : un e-mail, un tableur, un CRM et une facturation, reliés par trois ressaisies manuelles. Après : un service lit la demande avec des règles et un modèle d’IA contrôlé, met à jour le CRM directement, et la facturation après une validation humaine. ressaisieressaisieressaisie E-mailTableurServiceRèglesIA contrôléeCRMFacturationValidation
  • Règle même entrée, même résultat
  • IA pour ce qui varie trop, avec un contrôle
  • Intégration échange avec vos systèmes par API
  • Personne décide là où une erreur coûte
  1. Une demande arrive par e-mail.

    Rédigée librement, parfois incomplète, dans la langue du client.

  2. Quelqu’un la recopie dans un tableur.

    Pour la suivre et la chiffrer à la main, quand il en trouve le temps.

  3. Puis dans le CRM, puis dans la facturation.

    Les mêmes données saisies trois fois. Chaque copie est une erreur possible, et plus personne ne sait quelle version fait foi.

  4. Le tableur devient un service.

    Il lit chaque demande à l’arrivée. Des règles extraient ce qui est prévisible ; un modèle d’IA lit ce qui varie trop, et sa réponse est contrôlée.

  5. Vos outils se mettent à jour seuls.

    Par API : le CRM et la facturation reçoivent les mêmes données, une seule fois, avec une trace de chaque échange.

  6. Une personne valide ce qui compte.

    Le devis, le cas douteux, l’exception. Le reste avance sans attendre.

Schéma illustratif. Chaque projet part de votre processus réel, de vos outils et de vos exceptions.

Un message en texte libre, traité de bout en bout

L’exemple d’une entreprise de nettoyage qui reçoit des demandes rédigées librement, en plusieurs langues. Ce petit système les lit, contrôle ce qui manque, calcule le prix, enregistre la demande via une API et prépare les réponses ; une personne valide avant l’envoi. Il s’exécute dans votre navigateur et rien n’est envoyé. Choisissez un exemple ou écrivez votre propre message, puis ouvrez chaque étape.

Tarifs fictifs, pour la démonstration.

Le traitement, étape par étape

Réception

Règle

Le message est reçu tel quel. Une règle simple reconnaît la langue à partir des mots les plus courants, pour répondre au client dans la sienne.

Langue détectée
—
Longueur
—
Reçue à
—
  • Règle même entrée, même résultat
  • IA pour ce qui varie trop, avec un contrôle
  • Intégration échange avec vos systèmes par API
  • Personne décide là où une erreur coûte

Des demandes, des documents ou des données arrivent en texte libre et quelqu’un les ressaisit ?

Décrivez-nous votre processus

Ce que nous construisons

Souvent combinés dans un même projet. La technologie est un moyen : elle se choisit selon le problème, jamais l’inverse.

Ce que nous construisons Concrètement Avec
IA appliquée Lecture de documents et d’e-mails, extraction d’informations, tri des demandes, assistants et recherche dans vos documents. Toujours avec un contrôle, et seulement là où une règle ne suffit pas. Modèles de langage (LLM) via API, agents, RAG, évaluation des résultats
Automatisation des processus Processus métier automatisés de bout en bout : déclenchement, contrôles, envoi vers les bons systèmes, validation humaine sur les exceptions. Workflows, traitements planifiés, files de messages, notifications
Intégrations et API Connexion à vos ERP, CRM, paiements et services tiers ; données synchronisées entre systèmes, sans ressaisie. REST, webhooks, Kafka, connecteurs sur mesure
Applications et outils internes Applications web sur mesure, outils internes, portails clients, plateformes et produits SaaS. Java, Spring Boot, React, TypeScript, Node.js, PostgreSQL
Applications mobiles Applications pour téléphone et tablette : installables depuis le navigateur (PWA) ou publiées sur l’App Store et Google Play, selon le besoin. PWA, React, React Native
Sites web Sites rapides, multilingues et bien référencés, reliés à vos outils pour que les demandes ne se perdent pas. HTML, CSS, JavaScript, React, CMS selon le besoin
Réservation, paiement et e-commerce Réservation en ligne reliée à votre agenda, paiements en ligne et boutiques, avec confirmations et e-mails automatiques. Agendas, paiement en ligne, boutique sur mesure ou CMS
Mise en production et données Déploiement, hébergement et surveillance ; tableaux de bord, rapports automatiques et pipelines de données. Docker, Kubernetes, Cloud, CI/CD, SQL, Flyway
Maintenance et hébergement Abonnement mensuel : mises à jour de sécurité, sauvegardes, surveillance, corrections et petites évolutions, par quelqu’un qui connaît votre système. Surveillance, sauvegardes, alertes, CI/CD
Audit et reprise d’applications État des lieux d’une application existante (code, architecture, infrastructure, sécurité), puis correction, modernisation et documentation. Revue de code, tests, migrations, documentation

Et chez vous, où est-ce que ça coince ?

Six situations fréquentes. Choisissez la plus proche de la vôtre : le processus d’aujourd’hui, le système qui y répond, la place de l’IA et celle d’une personne, et ce qu’il faut clarifier avant d’écrire une ligne de code.

IA + automatisation

Aujourd’hui

Factures, bons de commande ou formulaires arrivent en PDF et par e-mail ; quelqu’un les ouvre un par un et recopie montants, références et dates.

Ce qui coince

Le volume monte plus vite que l’équipe, les erreurs de frappe passent inaperçues et les documents attendent dans la boîte de réception.

Ce que nous construisons

Les documents sont lus automatiquement, les informations extraites puis contrôlées. Une personne ne regarde que les cas douteux.

Le flux

  1. PDF et e-mails
  2. Extraction par IA (IA)
  3. Contrôle de cohérence (Règle)
  4. Cas douteux vers une personne (Personne)
  5. Votre système (Intégration)

IA ou règles ?

L’IA lit ce qui change d’un expéditeur à l’autre : mise en page, formulations, langues. Les contrôles restent des règles : totaux recalculés, numéros de TVA, montants plausibles, doublons.

Contrôle humain et risques

Le risque : une valeur mal lue mais plausible. Chaque extraction porte un niveau de confiance ; sous un seuil fixé ensemble, le document va à une personne, et chaque correction est gardée pour mesurer la qualité.

À clarifier avant de commencer

  • Combien de documents par mois, et combien de modèles différents ?
  • Quelles données faut-il extraire, et où vont-elles ensuite ?
  • Les documents peuvent-ils être traités hors de vos serveurs ?

Réalisé typiquement avec

Des modèles de langage (LLM) via API là où les documents varient trop, des règles là où elles suffisent.

C’est aussi mon cas

Automatisation

Aujourd’hui

Chaque semaine, quelqu’un exporte des données d’un outil, les vérifie dans un tableur, puis les envoie ou les ressaisit ailleurs, toujours dans le même ordre.

Ce qui coince

Des heures sans valeur ajoutée, un processus qui s’arrête quand la personne est absente, et aucune trace de ce qui a été fait.

Ce que nous construisons

Le processus est automatisé de bout en bout : déclenchement, contrôles, envoi vers les bons systèmes. Une personne n’intervient plus que sur les exceptions.

Le flux

  1. Déclencheur
  2. Contrôles (Règle)
  3. Systèmes cibles (Intégration)
  4. Exceptions vers une personne (Personne)
  5. Journal d’exécution (Règle)

IA ou règles ?

Souvent, pas d’IA du tout : si les étapes sont toujours les mêmes, des règles sont plus fiables, plus rapides et moins chères. L’IA n’entre que si une étape demande de lire du texte libre.

Contrôle humain et risques

Le risque : une automatisation qui échoue en silence. Chaque exécution est journalisée, une erreur déclenche une alerte et chaque exception arrive chez une personne avec tout son contexte.

À clarifier avant de commencer

  • Qu’est-ce qui déclenche le processus, et à quelle fréquence ?
  • Quels outils sont concernés, et ont-ils une API ?
  • Qui doit être prévenu quand quelque chose sort de l’ordinaire ?

Réalisé typiquement avec

Java et Spring Boot, Python ou Node.js, avec une file de messages quand le volume l’exige.

C’est aussi mon cas

Intégration

Aujourd’hui

Un client est créé dans le CRM, puis une seconde fois dans la facturation ; un devis accepté est recopié dans l’ERP.

Ce qui coince

Des données qui divergent d’un outil à l’autre, des factures envoyées à une ancienne adresse, et du temps perdu à chercher la bonne version.

Ce que nous construisons

Une connexion par API synchronise clients, devis et factures dans les deux sens, et garde une trace de chaque échange.

Le flux

  1. CRM (Intégration)
  2. Service d’intégration (Règle)
  3. Facturation (Intégration)
  4. Journal des échanges (Règle)

IA ou règles ?

Pas d’IA ici : une synchronisation doit être exacte et prévisible. Ce sont des règles de correspondance entre champs, écrites et testées.

Contrôle humain et risques

Le risque : deux modifications contradictoires au même moment. On définit quel système fait foi pour chaque donnée ; un conflit est signalé au lieu d’être écrasé.

À clarifier avant de commencer

  • Quels logiciels, et lesquels proposent une API ?
  • Pour chaque donnée, quel système fait foi ?
  • Faut-il reprendre l’historique existant ?

Réalisé typiquement avec

API REST et webhooks, avec une file de messages comme Kafka si le volume le demande.

C’est aussi mon cas

Outil interne

Aujourd’hui

Une demande commence dans un e-mail, continue dans un tableur partagé, se valide par message et se termine dans un dossier.

Ce qui coince

Personne n’a de vue d’ensemble : où en est la demande, qui l’a validée, quelle version est la bonne.

Ce que nous construisons

Une application interne réunit les étapes au même endroit : saisie, suivi, validation et historique, avec des droits par personne.

Le flux

  1. Saisie
  2. Étapes du processus (Règle)
  3. Validation (Personne)
  4. Historique (Règle)
  5. Tableau de bord

IA ou règles ?

L’IA n’est pas le cœur du sujet. Elle peut aider à la marge, par exemple pour résumer une demande longue ou proposer une catégorie ; les étapes et les droits restent des règles.

Contrôle humain et risques

Le risque : un outil qui impose une façon de travailler qui ne colle pas au terrain. Il se construit par étapes, avec les personnes qui l’utiliseront, et chaque action est historisée.

À clarifier avant de commencer

  • Qui intervient, à quelle étape, avec quels droits ?
  • Quelles informations doivent être visibles, et par qui ?
  • Quels outils actuels doit-il remplacer ou rejoindre ?

Réalisé typiquement avec

React pour l’interface, Spring Boot et PostgreSQL derrière, avec gestion des utilisateurs et des rôles.

C’est aussi mon cas

Plateforme sur mesure

Aujourd’hui

Un prototype, une maquette ou un premier outil bricolé montre que l’idée tient, mais il ne supportera ni plus d’utilisateurs ni de vrais paiements.

Ce qui coince

Réécrire sans plan coûte cher ; continuer sur une base fragile coûte plus cher encore.

Ce que nous construisons

Une application web complète, pensée pour évoluer : comptes et rôles, logique métier, API, paiements si nécessaire, déployée et surveillée.

Le flux

  1. Vos utilisateurs
  2. Application web
  3. API (Intégration)
  4. Base de données
  5. Déploiement continu

IA ou règles ?

L’IA n’est pas une fin en soi : elle s’ajoute là où elle sert le produit, par exemple pour la recherche ou l’assistance, derrière une API qui la contrôle.

Contrôle humain et risques

Le risque : construire trop avant d’avoir des utilisateurs. Une première version limitée part en production, puis chaque étape s’appuie sur l’usage réel. Sécurité, droits et sauvegardes dès le départ.

À clarifier avant de commencer

  • Qui sont les utilisateurs, et que doivent-ils pouvoir faire dès la première version ?
  • Faut-il gérer des comptes, des rôles, des paiements ?
  • Où l’application doit-elle être hébergée ?

Réalisé typiquement avec

React pour l’interface, Java et Spring Boot ou Node.js derrière, PostgreSQL, Docker et CI/CD.

C’est aussi mon cas

Site web

Aujourd’hui

Le site a plusieurs années, il est lent sur mobile et n’existe que dans une langue ; les rares demandes arrivent dans une boîte mail que personne ne suit.

Ce qui coince

Des clients qui ne vous trouvent pas, ou qui repartent avant d’avoir compris ce que vous faites.

Ce que nous construisons

Un site rapide, en plusieurs langues, bien référencé, dont les demandes arrivent directement dans vos outils au lieu de se perdre dans une boîte mail.

Le flux

  1. Recherche Google
  2. Site multilingue
  3. Formulaire de demande
  4. CRM ou agenda (Intégration)
  5. Suivi des demandes

IA ou règles ?

L’IA peut aider à trier ou pré-qualifier les demandes reçues, mais le site doit d’abord être rapide, clair et bien référencé.

Contrôle humain et risques

Le risque : un beau site que personne ne trouve. Performance, accessibilité et référencement sont mesurés avant la mise en ligne, et chaque demande arrive chez la bonne personne.

À clarifier avant de commencer

  • Qui sont vos clients, et que cherchent-ils en arrivant sur le site ?
  • Dans quelles langues ?
  • Où les demandes doivent-elles arriver ?

Réalisé typiquement avec

HTML, CSS et JavaScript ou React selon le projet, SEO technique et accessibilité.

C’est aussi mon cas

Un projet réel, en production

Le site et le système de réservation de La Petite Ménagère, entreprise de nettoyage en Valais. La même démarche que dans les cas ci-dessus : des règles là où elles suffisent, une personne là où se prend la décision.

Page d’accueil de lapetitemenagere.ch : « Choisissez l’heure. Nous nous occupons du reste. », avec la mascotte de l’entreprise.
Calendrier de réservation de lapetitemenagere.ch : quatre créneaux choisis le jeudi de 10 h à 12 h, les heures indisponibles hachurées, et le récapitulatif de la demande.
Captures du site en ligne. Les disponibilités du calendrier sont un exemple.
Voir lapetitemenagere.ch (nouvel onglet)

La Petite Ménagère

Nettoyage professionnel, ValaisEn production

Le besoin

Que les clients réservent en ligne, directement dans l’agenda Google de la responsable, sans qu’une heure déjà prise puisse leur être proposée, et que la décision lui reste : c’est elle qui confirme chaque rendez-vous.

Ce que nous avons construit

Le site en six langues, le calendrier de réservation, le serveur qui le relie à l’agenda, les e-mails au client et à la responsable, et la mise en ligne automatique.

Le flux

  1. Le client choisit ses créneaux
  2. Contrôle : libre, 2 h minimum, trajet compris (Règle)
  3. Rendez-vous « à confirmer » dans l’agenda Google (Intégration)
  4. La responsable confirme ou refuse depuis l’e-mail (Personne)
  5. Confirmation au client, avec le fichier d’agenda (Intégration)

IA ou règles ?

Des règles, sans IA : rien ici ne demande d’interpréter un texte. Cases de 30 minutes, visite de 2 h minimum, 30 minutes de trajet entre deux clients. La grille affichée et l’acceptation de la demande appliquent la même règle : ce qui paraît libre est ce qui est accepté.

Contrôle humain et risques

Chaque jour demandé se décide à part : confirmé à une ou deux personnes (à deux, l’agenda ne bloque qu’environ la moitié du temps), ou refusé, et l’heure redevient libre. Le client reçoit la réponse dans sa langue.

Ce qui est vérifié automatiquement

  • Dix clients demandent la même heure au même instant : un seul l’obtient.
  • Si l’agenda Google ne répond pas, rien n’est enregistré à moitié et la responsable est prévenue.
  • Ce que le client écrit n’est jamais interprété comme du code dans les e-mails.
  • Parcours de réservation et accessibilité testés dans un vrai navigateur.
  • À chaque mise en ligne, si la nouvelle version ne répond pas, la précédente revient d’elle-même.
  • Les tests utilisent la même base de données qu’en production, PostgreSQL. Chaque changement de sa structure est versionné, testé, puis appliqué automatiquement à la mise en ligne.

Réalisé avec

React, TypeScript, Tailwind CSS · Java 17, Spring Boot, PostgreSQL, Flyway · Testcontainers, Docker, Playwright · Google Calendar API · GitHub Actions, Caddy

Cette page est aussi une démonstration

Un logiciel se juge à la façon dont il est construit. Voici ce que votre navigateur vient de mesurer en chargeant cette page.

Cette page, en direct

Chargement complet
…
Données transférées
…
Fichiers chargés
…
Langues disponibles
6
Traceurs sans votre accord
…
Appels à des polices externes
…

Mesures réelles de votre navigateur (API Performance). Elles varient selon la connexion et le cache.

La même exigence dans chaque projet

  • Code versionné et couvert par des tests automatisés
  • Déploiement automatisé (CI/CD) et environnements reproductibles avec Docker
  • Sécurité dès la conception : authentification, droits par rôle, journalisation
  • Performance et accessibilité mesurées, pas supposées
  • IA intégrée avec des contrôles, là où elle apporte quelque chose
  • Documentation et transmission, pour que le système ne dépende pas d’une seule personne

Audit Lighthouse du 17 octobre 2026 : 100 en accessibilité, bonnes pratiques et SEO.

Portrait de Marcos Fernandez, fondateur de Schweltai

Une startup valaisanne, un seul interlocuteur

Schweltai conçoit et développe des logiciels sur mesure pour les entreprises : applications, intégrations, automatisation et IA appliquée. Elle a été fondée en 2026 par Marcos Fernandez, développeur full stack.

Marcos développe du logiciel d’entreprise depuis 2022, d’abord dans de grands groupes de conseil et de technologie (Capgemini, Indra Group, Ricoh Europe), puis pour ses propres clients. Schweltai apporte les mêmes pratiques aux entreprises de la région : code versionné et testé, mise en production automatisée, documentation, et un système que quelqu’un d’autre pourra reprendre.

Aujourd’hui, il conçoit et écrit le code de chaque projet : vous parlez directement à la personne qui construit votre système, en français, en anglais ou en espagnol. Ce que nous construisons s’adresse, lui, à vos clients dans leur langue : français, allemand, italien, anglais, espagnol ou portugais. L’équipe grandira avec les projets.

Fondée en
2026
Basée en
Valais, Suisse
Fondateur
Marcos Fernandez, développeur full stack
Parcours du fondateur
Capgemini, Indra Group, Ricoh Europe, depuis 2022
Langues de travail
Français, anglais, espagnol
Projets multilingues
FR, DE, IT, EN, ES, PT
Technologies
Java, Spring Boot, React, TypeScript, Node.js, Python, PostgreSQL, Flyway, Docker, Testcontainers, Kubernetes, Kafka, Cloud, LLM
Hébergement
Nos serveurs, votre hébergeur ou votre cloud

Comment on travaille

Six étapes, chacune avec quelque chose de concret à la fin.

  1. Comprendre

    On regarde ensemble comment le travail se fait aujourd’hui, avec les vrais fichiers et les vrais cas.

    Vous recevez Une description écrite du processus et de ce qui coince.

  2. Concevoir

    Nous proposons une solution, une architecture et un périmètre réaliste pour une première étape.

    Vous recevez Un schéma, un devis et un planning.

  3. Construire

    Développement par étapes, avec des versions que vous pouvez tester.

    Vous recevez Des versions utilisables au fil du projet.

  4. Intégrer

    Connexion à vos outils existants et reprise de vos données.

    Vous recevez Des outils qui échangent leurs données.

  5. Mettre en production

    Déploiement sur un serveur choisi ensemble, avec sauvegardes et surveillance.

    Vous recevez Un système en service.

  6. Améliorer

    Suivi, corrections et évolutions quand votre façon de travailler change.

    Vous recevez Un système qui suit votre entreprise.

Questions fréquentes

Combien coûte un projet ?

Cela dépend de ce qu’il faut construire. Le premier échange est gratuit et sans engagement ; ensuite, vous recevez un devis pour une première étape clairement délimitée.

Vous utilisez l’IA partout ?

Non. Quand une règle simple suffit, nous utilisons une règle : c’est moins cher, plus rapide et vérifiable. L’IA sert là où les données sont trop variées, par exemple des documents rédigés librement.

Comment évitez-vous les erreurs de l’IA ?

En ne lui confiant que ce qu’une règle ne sait pas faire, en vérifiant chaque réponse (format, valeurs plausibles, cohérence avec vos données) et en envoyant les cas douteux à une personne. Chaque décision est journalisée, pour pouvoir être vérifiée et améliorée.

Nos données partent-elles chez un fournisseur d’IA ?

Seulement si vous l’acceptez, et seulement ce qui est nécessaire. Selon la sensibilité des données, on choisit ensemble un fournisseur avec des garanties contractuelles adaptées, un modèle exécuté sur votre infrastructure, ou pas d’IA du tout.

Pouvez-vous reprendre une application existante ?

Oui. Nous commençons par un état des lieux du code, de l’architecture et de l’infrastructure, puis nous décidons ensemble quoi corriger, moderniser, automatiser ou conserver.

Avec quelles technologies travaillez-vous ?

Celles qui conviennent au problème et à votre environnement. Notre base : Java, Spring Boot, React, TypeScript et PostgreSQL, avec Docker, Kubernetes, Kafka et le cloud. Les tests tournent sur une vraie base de données (Testcontainers) et son schéma évolue par migrations versionnées (Flyway). Nous utilisons aussi Node.js, Python ou des modèles de langage quand ils sont plus adaptés. Chaque choix est expliqué et documenté, pour que votre système ne dépende pas d’une seule personne.

Où sont hébergées les données ?

On le décide ensemble au départ : sur un serveur que nous gérons, chez votre hébergeur ou dans votre cloud.

Qui travaille sur mon projet ?

Marcos Fernandez, fondateur de Schweltai, conçoit et développe votre système et reste votre interlocuteur du début à la fin, en français, en anglais ou en espagnol. L’équipe grandira avec les projets ; vous saurez toujours qui travaille sur le vôtre.

Et après la mise en ligne ?

Nous proposons un abonnement de maintenance : mises à jour de sécurité, sauvegardes, surveillance, corrections et petites évolutions. Si vous préférez, votre équipe ou un autre prestataire peut reprendre le système : il est documenté pour ça.

Une startup, n’est-ce pas un risque ?

Votre système est construit pour ne dépendre de personne : code versionné, testé et documenté, déployé sur l’infrastructure de votre choix. Si un jour vous changez de prestataire, une autre équipe peut le reprendre.

Dites-nous ce que vous voulez construire

Quelques lignes suffisent : le problème, les outils concernés, ce que vous aimeriez qu’il se passe.

Ce qui se passe ensuite

  1. Marcos lit votre message et vous répond personnellement, avec des questions précises ou une première piste.
  2. Si le projet s’y prête, on fixe un premier échange, gratuit et sans engagement, avec vos vrais fichiers et vos vrais cas.
  3. Vous recevez une proposition pour une première étape clairement délimitée : périmètre, prix et planning.

Ou directement

Ce que vous cherchez

Votre demande

Rien n’est envoyé depuis ce site : le bouton ouvre votre messagerie ou WhatsApp avec le texte prêt.