بناء CRM حقيقي بالبرمجة بالوصف: من متطلبات المنتج إلى نظام يعمل على الإنترنت

ليس شاشة جميلة يولّدها الذكاء الاصطناعي، بل منتج حقيقي: مستخدمون وصلاحيات، وبيانات عملاء حسّاسة، وقاعدة MySQL، وواجهة برمجية محميّة، ونشر على استضافة مع HTTPS، وتطبيق ويب قابل للتثبيت. خريطة كاملة لقيادة الوكيل في مشروع من الحجم الذي يُدفع فيه مال.

فريق INTXA 10 دقائق قراءة حُدِّث في 23 سبتمبر 2026

حتى الآن بنينا صفحات مكتفية ذاتيًّا تعمل في المتصفّح. هذا الدرس قفزة إلى نوع آخر من العمل: منتج حقيقي بمستخدمين وبيانات وخادم. لن نطلب من الذكاء الاصطناعي «شاشة جميلة»، بل نبدأ من متطلبات المنتج، ونبني قاعدة البيانات والواجهة البرمجية والحماية، ثم ننقل المشروع إلى استضافة حقيقية ونختبره كمستخدم فعلي.

7جداول في قاعدة البيانات
2دوران: مدير وموظف
6وحدات تُبنى واحدة بعد أخرى
الاستاك

التقنيات

HTML وCSS وJavaScript، مع PHP 8.2 وMySQL؛ وهي متاحة في أغلب الاستضافات المشتركة.

النشر

البيئة

استضافة ونطاق وشهادة HTTPS.

الناتج

التسليم

تطبيق ويب، وتطبيق PWA قابل للتثبيت على الهاتف.

لماذا CRM تحديدًا؟#

لأنه يعلّمك ما لا تعلّمه الصفحات المنفردة:

  • مستخدمون وصلاحيات: مدير وموظفون، وكل مستخدم يرى فقط ما تسمح به الصلاحيات المطبّقة على الخادم.
  • بيانات حقيقية: عملاء وصفقات وملاحظات ومهام؛ فالخطأ هنا ليس عيبًا بصريًّا، بل قد يكشف بيانات أو يفقدها.
  • بيئة إنتاج: الانتقال من جهازك إلى استضافة حقيقية بإعدادات مختلفة وقاعدة بيانات وHTTPS ونسخ احتياطية.

نطاق النسخة الأولى: ماذا يدخل، وماذا نؤجّل عمدًا؟#

داخل النسخة الأولى

  • تسجيل دخول وإدارة مستخدمين، وصلاحيات مدير وموظف.
  • إدارة العملاء، والصفقات ومراحلها، والمهام والمتابعة.
  • سجل الأنشطة، وقاعدة معرفة داخلية، وبحث عربي.
  • لوحة مؤشّرات أساسية، وتطبيق PWA قابل للتثبيت.

خارجها عمدًا

  • محاسبة وفواتير ضريبية كاملة، وبوابات دفع، وتكاملات بنكية.
  • حملات واتساب جماعية.
  • تطبيق أصلي للمتاجر.
  • تعدّد المستأجرين المعقّد.
  • ردود مولَّدة بالذكاء الاصطناعي داخل النظام.

الأدوار#

مدير

المدير

يرى كل العملاء والصفقات والتقارير، ويدير المستخدمين، وينشر مقالات قاعدة المعرفة ويعدّلها.

موظف

الموظف

يصل إلى السجلات المسموح له بها فقط، ويضيف المتابعات والأنشطة، ويقرأ قاعدة المعرفة.

عميل

العميل النهائي

لا حساب له في النسخة الأولى؛ النظام داخلي لفريق الشركة، لا بوابة عملاء.

المتطلبات الوظيفية#

ماذا يفعل النظام؟

  • إنشاء المدير عند أول تشغيل، ودعوة الموظفين.
  • تسجيل دخول وخروج بجلسة آمنة.
  • كلمات المرور تُخزَّن مجزّأة (hash) لا نصًّا صريحًا.
  • إمكانية إبطال الجلسات بحسب التصميم.

المتطلبات غير الوظيفية: كيف يجب أن يعمل؟#

سرعة

أداء مقيس

هدف واقعي لزمن التحميل يُقاس في البيئة الفعلية، بدل وعد ثابت بـ «أقل من 3 ثوانٍ» لكل الأجهزة والشبكات.

وضوح

تجربة عربية

اتجاه RTL صحيح، ورسائل خطأ مفهومة، وأزرار مناسبة للهاتف، وتجربة لا تعتمد على الإنجليزية.

أمان

من البداية

HTTPS، وصلاحيات على الخادم، وتجزئة كلمات المرور، وحماية CSRF، وتحقّق من المدخلات، واستعلامات مُعدّة، وعدم كشف الأسرار.

استعادة

نسخ مختبرة

نسخ احتياطية منفصلة، مع اختبار الاستعادة؛ فوجود ملف نسخة لا يعني أنه يُستعاد.

البنية: المتصفّح لا يتصل بقاعدة البيانات مباشرة#

  1. المتصفّح أو تطبيق PWA

    الواجهة وJavaScript فقط.

  2. الهوية والصلاحيات

    من أنت؟ وهل يحقّ لك هذا الفعل على هذا السجل؟

  3. منطق العمل والتحقّق

    القواعد والتحقّق من كل قيمة واردة.

  4. MySQL

    لا يصل إليها إلا الخادم، باستعلامات مُعدّة.

كيف نمنع الوكيل من بناء نظام غير آمن؟#

Identity

الهوية

الدخول، والجلسات الآمنة، وتجزئة كلمات المرور، وإبطال الجلسات عند الحاجة.

I/O

المدخلات والمخرجات

التحقّق على الخادم، والاستعلامات المُعدّة، وتهريب المخرجات، وحماية CSRF.

Infra

البنية التحتية

HTTPS، والأسرار خارج Git، ومعالجة أخطاء لا تكشف التفاصيل، ونسخ احتياطية، وسجلات مناسبة.

الأمن ليس ميزة نضيفها في النهاية؛ إنه جزء من البنية منذ أول أمر.

نموذج البيانات#

الجدولالغرضحقول مهمة
usersالمستخدمونid, name, email, password_hash, role, active, created_at
clientsالعملاءid, owner_id, name, phone_normalized, source, status, created_at
dealsالصفقاتid, client_id, title, stage, value, currency, close_date
tasksالمهامid, client_id, deal_id, assigned_to, title, due_at, completed_at
activitiesسجل الأنشطةid, client_id, user_id, type, body, occurred_at, created_at
kb_categoriesأقسام المعرفةid, title, sort_order
kb_articlesمقالات المعرفةid, category_id, title, body, status, author_id, updated_at

لاحظ owner_id في جدول العملاء: هو ما يجعل قاعدة «الموظف يرى عملاءه فقط» قابلة للتطبيق في كل استعلام.

نبني محليًّا قبل أن نلمس الإنتاج#

  • PHP 8.2 أو إصدار مدعوم، وMySQL محلية عبر Laragon أو XAMPP، وComposer عند الحاجة، وGit، ومتصفّح حديث.
  • إن اخترت Node.js فتحقّق أولًا من أن خطة الاستضافة تدعمه فعلًا قبل اعتماد المسار.

سير العمل: لا تقل للوكيل «ابنِ المشروع كله»#

  1. ملخّص المنتج

    المستخدمون، والمشكلة، والنطاق، ومعايير النجاح.

  2. البنية

    الواجهة والواجهة البرمجية والهوية وقاعدة البيانات، قبل أي كود.

  3. المخطّط وعقد الواجهة البرمجية

    الجداول والعلاقات والمسارات المطلوبة، قبل بناء الشاشات.

  4. الوحدات بالترتيب

    الدخول ← العملاء ← الصفقات ← المهام ← قاعدة المعرفة ← PWA.

  5. اختبار ثم حفظ ثم متابعة

    كل وحدة تعمل وتُحفظ في Git قبل الانتقال إلى التالية.

ملف القواعد: اجعل الوكيل يعرف حدود المشروع#

ما يحتويه AGENTS.md

  • البنية المعتمدة وقواعد تسمية الملفات.
  • قواعد الأمان وقواعد الوصول إلى قاعدة البيانات.
  • لا تغييرات واسعة دون موافقة، ولا مكتبات جديدة دون سبب.

قواعد ثابتة لا تُناقش

  • كل صلاحية تُفحص على الخادم.
  • لا أسرار في Git، ولا بيانات دخول الإنتاج في أي أمر.
  • لكل ميزة طريقة اختبار.
  • لا إعادة هيكلة شاملة أثناء ميزة صغيرة.

قاعدة المعرفة ثم تطبيق PWA#

  • قاعدة المعرفة: أقسام ومقالات، ومسودّة أو منشور، وبحث عربي، وصلاحيات نشر، وتاريخ تحديث ومؤلّف.
  • PWA: ملف Web App Manifest، وأيقونات مناسبة، وتجربة هاتف RTL، وService Worker عند الحاجة، وتخزين مؤقّت للمحتوى غير الحسّاس فقط.

من جهازك إلى الإنتاج#

مراحل النشر

  1. أنشئ قاعدة MySQL

    من أدوات قواعد البيانات في لوحة الاستضافة.

  2. أنشئ مستخدمًا لها

    ببيانات اتصال قوية وصلاحيات على هذه القاعدة فقط.

  3. استورد المخطّط

    schema.sql عبر phpMyAdmin أو ما يتيحه حسابك.

  4. بيانات التجربة منفصلة

    seed-dev.sql محليًّا فقط؛ ولا تُرفع حسابات تجريبية معروفة إلى الإنتاج.

أمر البناء النهائي#

لا تبدأ بالكود قبل أن تعطي الوكيل خريطة العمل كاملة:

أمر بدء المشروع
أنت تعمل مهندس برمجيات مسؤولًا عن بناء CRM عربي RTL قابل للنشر. قبل كتابة أي كود: حلّل المتطلبات، واقترح بنية واضحة، وصمّم مخطّط قاعدة MySQL، وحدّد عقد الواجهة البرمجية وقواعد الهوية والصلاحيات والأمان. ثم أنشئ خطة تنفيذ بالوحدات، ولا تنفّذ المشروع كله دفعة واحدة.

الاستاك: HTML/CSS/JavaScript + PHP 8.2 + MySQL.
الوحدات: Users, Clients, Deals, Tasks, Activities, Knowledge Base, PWA.

الموظف لا يصل إلا إلى السجلات المسموح له بها، وجميع الصلاحيات تُفحص على الخادم. استخدم Prepared Statements وServer-side Validation وCSRF Protection وPassword Hashing وSecure Session Handling.

أنشئ: schema.sql وseed-dev.sql و.env.example وAGENTS.md. لا تضع أي كلمة مرور للإنتاج أو مفتاح API داخل الكود أو Git أو هذا الحوار.

بعد كل وحدة: اشرح ما بُني، وطريقة اختباره، والحالات الحدّية، والمخاطر الأمنية المحتملة، قبل الانتقال إلى الوحدة التالية.

متى يُعدّ المشروع مكتملًا؟#

ليس لأنه يبدو جميلًا، بل حين يجتاز الثلاثة:

Live

يعمل على الإنترنت

رابط حقيقي عبر HTTPS يُفتح من جهاز وشبكة مختلفين.

Secure

آمن

المدير والموظف لا يتجاوزان صلاحياتهما، ولا أسرار مكشوفة، ولا بيانات تُصل دون تخويل.

Useful

مفيد

يمكن إضافة عميل، وتحريك صفقة، وإنشاء مهمة، ونشر مقال والبحث عنه.

اختبر فهمك

أخفيت زرّ «حذف عميل» عن الموظفين في الواجهة. هل هذا كافٍ؟

اختبر فهمك

أين توضع كلمة مرور قاعدة البيانات في الإنتاج؟

اختبر فهمك

لديك ملف نسخة احتياطية حديث. متى تثق به؟