Aller au contenu principal
qaryon

La création de qaryon : d'architecte solutions à fondateur

Pourquoi un expert UC avec 12 ans d'expérience a créé qaryon, comment le site a été construit avec Next.js 16, et ce que signifie 'on conçoit, on déploie'.

qaryonnext.jsentrepreneuriattelecomuc

Après plus de douze ans passés chez des intégrateurs et opérateurs télécom, j'ai créé qaryon en avril 2026. Ce n'est pas un acte impulsif — c'est la conséquence logique d'un constat récurrent : les intégrateurs télécom ont besoin d'expertise senior sur le terrain, pas dans un organigramme.

Cet article raconte pourquoi, comment j'ai construit le site, et ce que qaryon signifie concrètement pour un intégrateur ou un opérateur qui cherche un architecte solutions.

Le constat : un marché qui sous-traite l'expertise

Le cycle est toujours le même. Un intégrateur signe un contrat de déploiement UCaaS pour un client de 10 000 postes. L'avant-vente a été menée par un ingénieur senior qui connaît Microsoft Teams, les SBC AudioCodes, les subtilités du routage SIP et les contraintes réseau du client. Le client signe en confiance.

Puis le projet démarre, et l'ingénieur senior passe au dossier suivant. L'intégrateur affecte un profil plus junior au déploiement. Pas par mauvaise volonté — par structure. Les seniors sont rares, chers, et sur-sollicités. Le résultat : des projets qui dérapent sur des problèmes de configuration SBC, de qualité de service ou d'intégration multi-vendeurs que seul un profil expérimenté aurait anticipés.

J'ai vécu ce schéma des deux côtés. Côté intégrateur, en concevant des architectures que d'autres devaient déployer. Côté terrain, en intervenant sur des projets en difficulté pour les remettre sur les rails. Le gap entre la conception et l'exécution est le problème central du métier.

qaryon existe pour combler ce gap. Un expert senior qui conçoit et déploie. Pas de transfert vers un junior. Pas de sous-traitance. Le même interlocuteur du cadrage à la mise en production.

Pourquoi un site, et pourquoi maintenant

Créer une activité de conseil, c'est avant tout être visible. Dans l'écosystème B2B télécom, LinkedIn est le canal principal, mais il faut un point d'ancrage professionnel. Un site qui montre ce qu'on fait, comment on le fait, et qui permet de prendre contact.

J'aurais pu utiliser un CMS classique ou un constructeur de pages. Mais je suis développeur autant qu'architecte télécom. Construire le site moi-même était à la fois un choix de contrôle et une démonstration de compétence : si je prétends livrer des solutions techniques, le site doit en être une.

La stack technique : Next.js 16, React 19, Tailwind CSS 4

Le site tourne sur une stack moderne et minimaliste :

{
  "next": "16.2.3",
  "react": "19.2.4",
  "tailwindcss": "^4",
  "next-intl": "^4.9.0",
  "next-mdx-remote": "^6.0.0",
  "shadcn": "^4.2.0"
}

Next.js 16 et l'App Router

Le choix de Next.js 16 avec l'App Router n'est pas anodin. L'App Router apporte les Server Components par défaut — chaque page est rendue côté serveur sans JavaScript superflu envoyé au client. Pour un site vitrine B2B, c'est exactement ce qu'il faut : des pages rapides, un bon SEO, et un bundle client minimal.

La structure de routes suit la convention src/app/[locale]/ avec next-intl pour le routage bilingue :

// src/i18n/routing.ts
import { defineRouting } from "next-intl/routing"

export const routing = defineRouting({
  locales: ["fr", "en"],
  defaultLocale: "fr",
  pathnames: {
    "/": "/",
    "/services": "/services",
    "/about": "/about",
    "/contact": "/contact",
    "/portfolio": "/portfolio",
    "/blog": "/blog",
  },
})

Chaque page reçoit la locale via params (une Promise dans Next.js 15+) et appelle setRequestLocale pour configurer le contexte de traduction :

// src/app/[locale]/page.tsx
export default async function HomePage({ params }: Props) {
  const { locale } = await params
  setRequestLocale(locale)
  // ...
}

Pourquoi le bilingue dès le jour 1

qaryon cible des intégrateurs et opérateurs en France, mais aussi en Suisse et à l'international. Le site est bilingue français/anglais depuis le premier commit. next-intl gère les traductions via des fichiers JSON dans messages/fr.json et messages/en.json, avec le hook useTranslations dans les composants :

export function HeroSection() {
  const t = useTranslations("home.hero")
  return (
    <h1>{t("title")}</h1>
    // FR: "Architecte Solutions."
    // EN: "Solution Architect."
  )
}

Ce choix a un coût initial — chaque texte doit exister en deux langues — mais il aurait été beaucoup plus coûteux d'ajouter l'internationalisation après coup. L'architecture de routage, les métadonnées SEO, les images Open Graph : tout dépend de la locale.

Tailwind CSS 4 et shadcn

Tailwind CSS 4 avec PostCSS fournit le système de design. Les composants UI viennent de shadcn/ui (v4), qui génère des composants React directement dans le projet plutôt que de les importer depuis un package. Cela permet une personnalisation totale sans dépendance externe.

Le thème utilise deux polices chargées via next/font/google : Raleway (poids 300) pour le logo et la marque, Inter pour le contenu. La couleur primaire est un violet (#a855f7) qui traverse tout le site, de la hero section aux images Open Graph.

L'architecture du site : Server Components partout

La homepage est composée de six sections, toutes Server Components sauf le formulaire de waitlist qui nécessite de l'interactivité client :

// src/app/[locale]/page.tsx
<HeroSection />
<ServicesPreview />
<WhyQaryon />
<CtaSection />
<Testimonials />
<SaasTeaser />  {/* "use client" — contient le formulaire */}

Ce découpage est intentionnel. Un composant Server Component ne ship aucun JavaScript au navigateur. Pour un site vitrine, la quasi-totalité du contenu est statique : titres, descriptions, listes de services. Seul ce qui nécessite une interaction utilisateur (le formulaire de contact, la waitlist, le sélecteur de thème) est marqué "use client".

Le résultat : un premier chargement rapide, un score Lighthouse élevé, et un SEO natif puisque tout le contenu est dans le HTML initial.

Le blog : MDX sans CMS

Le blog utilise MDX via next-mdx-remote avec des fichiers stockés dans content/blog/. Pas de CMS, pas de base de données, pas d'API externe. Chaque article est un fichier .mdx avec un frontmatter YAML :

---
title: "La création de qaryon"
description: "..."
date: "2026-04-13"
tags: ["qaryon", "next.js"]
locale: "fr"
---

La librairie gray-matter parse le frontmatter, et next-mdx-remote rend le contenu MDX dans un Server Component. Les articles sont filtrés par locale — un fichier .fr.mdx n'apparaît que sur la version française du site.

Ce choix est cohérent avec la philosophie du projet : pas de dépendance externe, pas de service tiers, un déploiement simple sur Vercel via git push.

"On conçoit, on déploie" — pas juste un slogan

La section "Pourquoi qaryon" du site affiche trois piliers :

  1. Expert senior direct — pas d'intermédiaire, pas de junior en sous-traitance
  2. Approche livrables — chaque mission produit des résultats concrets (documentation, architectures, configurations)
  3. On conçoit, on déploie — pas seulement du conseil, mais de la livraison bout en bout

Ce troisième pilier est le coeur de la proposition. Dans le conseil télécom traditionnel, l'expert produit un document d'architecture et le remet à l'équipe projet. Avec qaryon, l'expert qui a conçu l'architecture est aussi celui qui configure les SBC, teste les flux SIP, et valide la qualité de service en production.

C'est exactement ce que fait ce site : je l'ai conçu, développé, optimisé et déployé. Les 45 commits du repository reflètent un processus itératif — de l'initialisation Next.js à l'optimisation des images Open Graph pour LinkedIn, en passant par les ajustements de contenu après mes propres revues.

Ce qui vient ensuite

qaryon est aujourd'hui une activité de conseil. Le site annonce déjà la suite : une plateforme SaaS pour les intégrateurs télécom, destinée à simplifier la gestion, le déploiement et le monitoring des infrastructures de communication.

La waitlist est ouverte sur la homepage. Le formulaire utilise Resend pour l'envoi d'emails, avec validation Zod côté serveur et react-hook-form côté client — la même rigueur technique que pour un déploiement VoIP.

En attendant, le travail continue : des missions de conseil, des articles techniques sur ce blog, et l'amélioration continue du site. Quarante-cinq commits en quatre jours, c'est un début. Le prochain chapitre s'écrit en production.

qaryon — Conseil, audit et formation en communications unifiées. Prendre contact.